密钥硬编码在代码里，这个错误我在 Code Review 里见过太多次

1. “那个，这里的 Key 能改一下吗？”

这是上周五下午 5:45，我准备下班时在 GitHub 上看到的一行代码：

const AES_KEY = "my-secret-password-123"; // TODO: Move to env

那一刻，我的血压瞬间升到了 140。这不仅仅是一个 TODO 的问题，这是一个随时可能引爆的安全炸弹。作为一名做了十年前端的“老甲鱼”，我深知这种“临时的方便”最终会导致怎样的灾难：从数据脱库到公司倒闭，往往只隔着一个被公开的 GitHub 仓库。

2. 为什么硬编码是自杀行为？

GitHub 是永恒的

即使你意识到错误并在下一秒删除了代码，Git 历史记录也会永远记得它。泄露后的密钥就像泼出去的水，唯一的补救逻辑是 **Key Rotation（更换密钥）**。如果你的业务已经上线，更换密钥意味着所有已加密的数据都变成了乱码。

逆向工程的低门槛

不要以为代码混淆（Obfuscation）能救你。对于一个稍微懂行的黑客来说，在 JS Bundle 里搜寻 16 位或 32 位的字符串就像在沙滩上捡贝壳一样简单。只要 Key 还在客户端代码里，你的加密逻辑就等同于“裸奔”。

3. AES vs DES：别再用那个“古董”了

在我们的工具箱里，虽然提供了 DES 工具，但我必须在文章里给出 **“红色警告”**。

• DES (Data Encryption Standard): 这种 70 年代的产物在今天只需要几百美元的算力就能快速破解。除非是为了兼容 20 年前的老银行系统，否则请离它远点。
• AES (Advanced Encryption Standard): 今天的金科玉律。至少使用 256 位，并且一定要配合 **IV (Initialization Vector)**。没有 IV 的 AES 就像没有锁芯的锁，容易遭受模式攻击。

4. 如何优雅地调试加密逻辑？

作为开发者，我们经常需要验证一段加密字符串是否正确。以前，大家会偷懒在 Console 里打印 Key，或者把 Key 写在本地临时脚本里。**这正是危险的开始。**

我在设计 daima.life 时，专门优化了 **本地调试流**：

1. 环境变量隔离：在你的 .env.local 里存放真实密钥。
2. 沙盒测试：当你需要验证逻辑时，直接打开 daima.life 的 AES 工具。
3. 零泄露承诺：因为我们的工具是 100% 纯前端执行，你输入的密钥只存在于浏览器的内存中。没有 API 请求，没有后端日志。这比你在任何“在线转换器”上测试都要安全一万倍。

5. 结语

安全不是一个功能，而是一种习惯。下次你在 Code Review 里看到硬编码的密钥，请把这篇文章甩给对方。保护好你的 Key，就是保护好你的职业生涯。欢迎使用 daima.life 的安全工具集，让我们一起把安全水位线再提高一点点。