javalaw2010

如果场景允许的话，先上个限流，避免下游无节制调用接口。
如果是收费接口，提高费用，下游会自己想办法做缓存。
如果场景允许静态化，那改成生成 json 文件分发到 CDN ，CDN 一般价格好谈一点。

鼻炎，湿疹，银屑病。

我们小时候做作业都在客厅做，爸爸妈妈都坐在同一张桌子上，想摸鱼？不可能的。作业完成的早还有时间玩会儿，到点儿了就弄上床睡觉了。

为什么会觉得这是在抢小开发者的饭碗呢，这俩明显是两条赛道啊。

腾讯那么多游戏开发团队，多少美术资源需要版本管理，你指望每个美术都学会用命令行敲 git 命令嘛？

纯静态网页？要不然 github pages 。

出国旅游，买了旅途变更险，果真遇上台风无法回国，原有航班没有航班供改签，高价买了第二天的机票，算上酒店食宿，赔付的钱基本完全覆盖了损失。

我本身是不想参与 V2 这种月经贴的讨论的，不过今天实在是太闲了，秉持着真理越辩越明的理论，我还是想再多理论两句。
> 密码加盐（每个网站的盐一般都不同）后 hash 传输，服务端存储的是与原明文密码没有任何逆向关系的字符串，所以即使多个网站使用相同的密码，也不会受到某个网站被脱裤后的影响

其实稍有编程常识的后端开发都会选择加密入库，不可能有人选择加密入库的。不过我们假设就有这样一个刚入行的愣头青，写了个明文入库的代码，好巧不巧，他被拖库了。黑客拿到了份数据库，得到了一个（ xiaoming, password123 ）的账户名和密码，他想使这样一个用户名密码来登录一个前端加密网站，此时他选择了最简单的办法，手动输入，他在用户名输入框里输入了 xiaoming ，在密码框里输入了 password123 ，而当时小明也在该网站输入了同样的用户名和密码，此时黑客点击登录，那么你觉得他是能登进去呢，还是不能呢？

> 基于第一点，HTTPS 是否是加密传输其实无所谓的，与密码的安全并无关系，遑论还有中间人攻击呢（不知道说的对不对，印象中是这个）
我不太明白是什么可以得出了 HTTPS 和密码的安全无关这样一个结论的，而中间人攻击，你的网站/APP/操作系统必须信任一个原则上不可信的第三方证书，中间人攻击才能得以实施。这意味着要么你主动信任了一个不可信的中间人，要么黑客得到了你的操作系统的控制权。而中间人攻击一旦得以成功实施，经过前端加密的密码，也不过是变成了另一个密码的明文而已。

实际上，要真正解决密码被拖库的碰撞问题，要使用的解决方案是二因素认证，而不是前端加密。