的确很多回复比较阴阳怪气, 好像这几乎是'没必要讨论的问题'.

我倒是觉得问题提的很不错. 忽略一些新手的错误,摘要一下值得讨论的是:
1. 前端加密是否更加安全. 这里的安全包括了 zero-trust 的概念, OPSEC 的准则, 以及很多人提到的, 是否会在其他阶段如 log 阶段泄露明文密码等. 这绝对不是没必要讨论的事情.
2. 如果前端加密更安全, 怎么做更安全? 会遇到什么问题? 如很多人提到的要加盐,还有人提到的'如何防止用户构造数据', 性能上和 portability 上会有什么影响. md5 不是加密,但是否 good enough?
这些都是更加值得讨论的.

md5 是摘要不是加密这是很多初学者会忽视的问题, 知乎上有很多类似案例.
很多人没必要抓着这个点就嘲笑 op,谁刚学没犯过一点错误.
甚至拿什么 V2 也明文或者贴上 hellworld 级别的代码告诉 op 后端会加密存储,就觉得讨论终结了...这种 arrogant 很难让人忍受, 真以为大家都是草台班子?

@Rnreck 笑死了, 跑的好快. 不过很多 fork. 不过我看了下代码其实也没什么特殊的. 爬虫就是一个耗费精力的事情.
@baobao1270 我试了下似乎未登录用户也可以查看 up 主投稿, 大概需要关闭一个弹出的登陆窗口. 偶尔的失败对于 RSS 应该是能接受的.
间隙的话, 2 小时以上的间隙应该可以接受吧? 应该不至于频率过高. RSS 也就每天一看

@codespots 如果前端用户看得到加密, 还需要担心后端服务器不负责任的储存密码嘛?
我觉得这是一个增加用户信任的 feature 而不是一个纯粹的安全性上的 feature.
当然, 的确也是比较鸡肋的 feature. 大厂没必要, 小厂我觉得大多数人也不会去扣前端代码, 担心明文储存会去看源码的人本身也不会用非随机密码.

@horizon 我的意思前端加密等于是告知用户密码不会明文储存, 从没说过明文传输等于明文储存 -- 这是一个用户和服务供应商相互信任的问题.
但是前端如果得到了妥善的加密, 就不需要用户和服务商互相信任这一环了. 我不用担心我的密码不会被妥善保存.

肯定是有意义的.
至少对于我来说就好比是我永远不会在稀奇古怪的网站上 (包括 V2EX xD) 用我的 master password, 只敢用随机密码.就是担心哪天这网站被扒做一些明文储存密码的事情.
然而如果是大厂我就无所谓了, 会用我自己常用的几个 master password.
如果前端可以看到密码是加密后传输的, 那我就少很多心理负担了.