隐式转换不是加盐，也不能替代加盐或哈希；它只是JS自动类型转换行为，结果确定、无随机性、易被逆向，不满足加盐所需的不可预测性、唯一性和可重现性。
隐式转换本身不是加盐，也不能替代真正的加盐或哈希。它只是 JavaScript 在运算中自动类型转换的行为（比如 "" + 123 → "123"，![] → false，+[1,2] → NaN）。有人会利用这类“看似随机又可复现”的转换结果，拼接进字符串参与简单混淆，但这不构成密码学意义上的加盐，也不提供任何实质安全防护。
为什么不能靠隐式转换做加盐
加盐的核心要求是：不可预测性 + 唯一性 + 可重现性（验证时需一致）。而隐式转换：
- 结果完全由输入结构和 JS 引擎规则决定，无随机性（比如
{}+[]永远是"[object Object]"） - 无法生成真正随机、高熵的 salt 值（如 16 字节 base64 随机串）
- 极易被逆向还原或静态分析（例如
String([])、1e3+""、!![]+""等写法在混淆工具里早被归类为固定模式） - 一旦被识别，整个“混淆”就形同明文
哪些隐式转换常被误用作“假加盐”
以下代码常见于低强度前端混淆，仅作示意，切勿用于密码、token 或敏感字段处理：
-
password + (+new Date())→ 利用时间戳转数字再隐式转字符串（但时间戳可预测、精度低、易重放） -
password + ([][0] + {})[10]→ 利用undefined[10]得到"i"这类 trick（纯字符级把戏，无熵值） -
password + ({} + [] + /a/).length→ 拼接对象、数组、正则再取长度（结果恒为固定数，如 32）
这些操作输出稳定、可穷举、无密钥控制，攻击者抓包一次就能推断全部逻辑。
立即学习“前端免费学习笔记（深入）”；
如果真想轻量混淆（非加密场景），可以这样组合
若仅用于防初级爬虫或参数显眼明文（如埋点 ID、非认证类 token），可结合真实随机与隐式转换做一层可读性遮蔽，但salt 必须来自 cryptographically secure 随机源：
- 用
crypto.getRandomValues(new Uint8Array(6))生成真随机字节数组 - 转成 hex 或 base64：
Array.from(bytes, b => b.toString(16).padStart(2,'0')).join('') - 再用隐式转换“包装”一下展示形式（仅视觉混淆）：
`${salt}-v${+new Date()}`或`${salt}${!0}${!1}`（后缀truefalse）
注意：这里的隐式转换只是拼接辅助，真正起混淆作用的是前面那串随机 salt —— 它才是唯一不可预测的部分。
正确做法：混淆 ≠ 加盐，加盐 ≠ 安全
前端永远不该承担主密码保护职责。真正该做的只有三件事：
- 传输前用
crypto.subtle.digest（SHA-256）或成熟库（如js-sha256）做哈希，且 salt 由后端动态下发（每次登录/注册不同） - 敏感密码绝不裸传，必须配合 HTTPS + CSRF Token + 后端二次哈希（带独立 salt）
- 所谓“混淆”，只应在非安全上下文中用于降低参数可读性（如 URL 中的 orderID），且应配合服务端校验逻辑，而非依赖前端逻辑藏密
