@xxss0903 你这涉及到字体等资源文件了，我只用 TypeScript 写过传统的逻辑库和 web 应用，没写过 web 组件库。

你可以参考与你项目类似的 pdf.js： https://www.npmjs.com/package/pdfjs-dist ，看它是怎么打包资源文件的。

当代软件开发都是需要包管理器的，学习包管理器就和学习编程语言一样，概念都是一通百通。npm 学习成本并不高，只不过在国内需要配置代理这项额外学习成本，建议用 pnpm 。

@CLMan 之前没看你项目源码，看了下，引入 vite-plugin-dts 是正确答案。

vite 是开发 web 应用的脚手架，你只是开发模块/库，如果不需要使用 web 页面进行辅助开发和测试，是不需要上 vite 的。

当然上了也不是什么错，毕竟可以利用其默认配置，比如 eslint 、prettier 相关默认设置。但是需要额外的配置，因为 vite 是面向 web 应用设计的，你用来开发库，其构建目标就和默认情况发生偏差，你需要添加额外的构建配置。

前面楼层提到的 package.json 里面的`exports`,`import`,`types`等字段，应该由构建工具来修改，不建议手动修改。

ESM 现在是主流的模块解决方案，webpack 这样的旧时代构建工具很少被使用了，构建工具有 rollup ，也包括前面提到的 tsup ，vite 是基于 rollup 的，所以你没必要引入额外的构建工具，当然你硬要用 tsup 也不会存在什么问题，只是 rollup 与 vite 集成度更高而已。

如过你使用 rollup ，就需要添加 rollup 的相关配置来构件库。你需要阅读 rollup 官网文档，以及 vite 官网的 rollup 部分的文档，了解如何添加构建库的配置。

这就是你这问题的相关解决思路。

个人只对桌面 GUI 跨平台有些了解。

wails 和 tauri 都是基于桌面系统自带的 webview ，优点是不需要像 electron 那样每个应用带一个运行时，但较老的 Windows 系统，得自带运行时的安装包或者下载器，或者让用户手动安装运行时。webview 的缺点就是性能较差，首屏加载有 0.5s~1s 的延迟。

如果对桌面 GUI 的性能有追求，那用 flutter 不错，磁盘占用、内存占用、性能都很优秀。

Compose Multiplatform 本质上就是 Java GUI ，试用过两个基于其开发的产品，内存占用和磁盘占用表现较差。

用过第一代 surface pro ，后来当泡面盖子了，对我个人而言没啥用。触控笔对于写程序的用处不大，其实际体验对于使用者的手写能力要求较高（比如专业绘画等），对个人而言不如键盘打字。

个人还是习惯传统笔记本，追求键盘手感。

不喜欢就放弃呗，又不是非学不可。我就尝试过 1 个月，后面就放弃了。

blake 部分原文指的应该是对用户明文进行 hash ，而你所指的是对派生密码进行 hash ，所以强度来讲确实没什么问题。

火狐的办法确实巧妙，因为它是拿用户明文生成的加密密钥，自然是不能上传明文密码，所以最好在客户端使用 KDF 。

@chenjia404 我懂你的意思了，因为 hash 函数的特点，1:N 这种对应关系，其中 N-1 个是无效值，即碰撞就是白费力气，那你的方案确实有趣。当然由于没有知识背景，我无法判断这种说法是否正确。

自从加盐哈希流行以后，安全界为啥还要建议使用 Bcrypt 、argon2 这些密码存储专用的哈希算法呢，无非是担心现有及以后的硬件暴力破解通用哈希算法太快。至于彩虹表，已经是上个过时版本了。

而你认为设计很好的点“ auth_hash 与 user 并非一一对应”，反而是最大的漏洞，因为它们其实是 N:1 的关系（ N 指 auth_hash 表的大小），意味着暴力破解时，可以碰撞的哈希值有 N 个。“这个表数据越多越好”，意味着破解的难度越低。

很多人以为，密码存储哈希值是避免用户的明文密码泄露，其实不然，是避免应用的明文密码泄露。如果是前者，那客户端密码 hash 早就流行开来了，还不至于成为开发者之间的争论点。对于后者，客户端密码 hash 毫无作用。

@liuidetmks 补充 @，内容见上一楼。

你这错得有点离谱，密码存储引入 hash 的历史原因有两个：

- 避免数据泄露，导致攻击者获得本应用的所有账户和明文密码
- 避免被拿去撞库

第一个是重中之重，影响了公司的生死存亡。第二个只能说是附带的，毕竟自己活着才最重要。

因为第一个原因，所以密码存储才经历了通用哈希算法、通用哈希算法+盐、标准密码哈希算法的技术演进。

而客户端 hash ，仅有的作用就是避免第二个原因，尚且属于程序员群体的争论点，并非最佳实践，大部分互联网公司都没有这么做。

现在你为了一点性能，将标准密码哈希算法丢到客户端，而服务端居然使用上古的通用哈希算法解决方案，连盐都舍不得加，不是捡了芝麻丢了西瓜。

事实上，你只要阅读一下你所推崇的 blake2 的官网，就会看到它根本不推荐将 blake2 用作密码存储：“Q: So I shouldn't use BLAKE2 for hashing user passwords?”，而是建议使用标准密码哈希算法。

你说的文件作为密码（或者说种子），KeePass 很早就支持用文件(Key File)了。

你如果是说文件、MD5 、base64/md5/sha256/自己的加密方案都属于生成主密码的前置步骤，那你加入的前置步骤越多，遗忘的概率越大。

“加密的方案只有自己知道”，从学院的角度来讲这会降低安全性，从现实的角度来讲，军用加密算法是非公开的、魔改的。但要实现类似后者的效果，你得有较深的密码学背景，不然就是前者描述的那类人。

很多之前不错的 PE 被收购了，以至于添加了毒。

长期没有接触一些垂直领域，避坑的方法是去相关的专业渠道询问，而不是自己百度一个然后闷头使用。

操作系统相关的专业渠道有远景论坛，稍微搜一下就不至于遇到类似的问题。

@CLMan

我推测你想表达的是，方案一强调 d,e 是可选参数，方案二强调 d,e 是必选参数。

我推测你想描述的场景是：d,e 可以完全由用户决定（后端只检查值的合理性），或者由后端提供值。
那通常是选择方案一，因为更简单，没必要多两个接口出来，对用户来说使用更加复杂。

你的设计方案，核心接口都是/create ，而且参数列表也是一致的，我没看出来有什么本质区别。

你的表述有些混乱，我帮你理清一下：

- 如果 d,e 是完全由用户决定，那为什么提供/get_d,/get_e ？

- 如果 d,e 由后端生成，用户选择，那提供/get_d,/get_e 是必然选项。

- 如果 d,e 完全由后端生成，那为什么提供/get_d,/get_e ，只需要参数列表 a,b,c 就行了，后端自己调用 get_d,get_e 。

可以参考别人的实现： https://github.com/emirpasic/gods/blob/master/stacks/arraystack/arraystack.go

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#dependencies

有的人习惯自己解决问题，有的人习惯问问题，过于独立或者过于依赖别人其实都不好。

@CodeCodeStudy NaN 是计算机为了满足数学需求搞出来的，在浮点数的标准 IEEE754 里面有规定，现代编程语言差不多都支持这个概念（因为都依赖于底层实现），这怎么能怪到 JS 去。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Invalid_date

Invalid Date 有点类似 null ，算个小坑，要在源头（ new Date()）进行检测（这意味着与其它编程语言并没有太大区别），后续代码并不需要防御性编程。

个人认为比较坑的，是 Array.isArray()这种需要额外记忆成本（因为浏览器跨框架的原因）的东西。