@CloudMx 对于后端来说，前端无论传的是密码原文还是 hash 后的值，在后端看来那都是“明文密码”，这点你能反应过来吗？比如用户密码 123456 ，sha256 一下就是 effff....16c 。那么对后端来说，effff......16c 就是明文密码。我是个攻击者，知道了你这串 effff....16c 直接用这个值请求登录 api 就登录进去了。前端你 hash 不 hash ，结果和明文密码并没任何不同


然后这里还有个问题，你有没有考虑过加盐 hash 到底应该在哪一步才好？
方法 1. 前端传密码原文，后端加盐 hash 入库
方法 2. 前端加盐 hash ，然后直接将结果入库

这里，比起方法 1 ，方法 2 是存在极其严重的安全漏洞的。加盐 hash 保证安全的前提是“盐是保密”这一点，前端加盐=盐被公开，当你盐被公开而后端又直接入库的话等同于用了方法 1 但后端的盐泄露了的情况。
所以前端加盐 hash 为了保证安全，那么你后端必须要再用另外的盐再 hash 一次：
方法 3. 前端加盐 hash ，后端再用另外一个盐 hash 入库
这时候方法 3 本质上和方法 1 并没任何不同（因为对后端来说无论你前端传什么过来对后端来说都是密码原文），只不过从一次 hash 变成了两次 hash 。那么这就又有个问题了，你都搞了两次 hash 了，为什么不为了安全后端多来几次，3 次，4 次，10 次，100 次？所以仅从数据入库角度来看，前端 hash 不能说脱裤子放屁，那也是没用处的