大量廉价可替换的劳动力。

技术理由不是没有，而是多到罄竹难书，但都算是细节，相比起来算是次要的。
真要说就有一个有代表性的：因为 project leader 水平问题，经常半吊子，完全无法一步到位，发版就是打补丁还不是 Java 那种用户自下而上推的那种，搞得底层生态发展自上而下地得半死不活。
比如 C# 2~4 ，先搞什么 anonymous method 再加 lambda 。你要是上道点，直接加 lambda 会死？特别是要知道历史上本来就先有的 lambda ，哪来你 method 什么事（当然严格来说你抄 Java 就注定是败笔了；类似的问题还有到处 method 不给 free function 再用 extension method 之类擦屁股等等，细想起来到处都是）。
虽然多加一个特性表面上就是多给了个选择，但是这类玩意儿根本是自上而下牵一发而动全身的，只有从上游推广，（因为传统的静态语言的先天问题）用户自己除非有本事整个重新实现一遍（也就有本事整出半吊子，比如 Mono ）都没法 derive （不像 JS 起码有自举的 Babel 这类； dynamic 这种补丁就算了），结果就是用户不得不被迫浪费精力了解这种半吊子设计，要么跳车要么就习惯基础技术时刻落伍。
要命的是这种微创新累积问题不是一个两个，官方还成习惯了，丝毫就没表现出要怎么克服改进。
而各种兼容性问题（像 @vone 提的）则是这种问题的一类表面上的体现。其实这种症状要只出现个例也还不是问题，但是多了工程上就很劝退了。

你要是 Java ，这还真不是太大的问题——本来 Java 用户平均来讲就是工业界里最容易在这方面被糊弄的又有强大的钉子户传统，最不怕的就是语言层次上的一成不变，嫌没事干可以头铁手动日 CheckedException 或者人肉翻译 XML 到 stacktrace 玩儿然后强行算成 framework 类似物的 KPI ，大多数用户都会默默接受习以为常；但.NET 除了软粉以外很多也就是从被 Java 糊弄不爽的状况下叛逃过去的，用户基数一开始就是问题，还玩碎片化？（还有大明湖畔的.NET CF……）岂不是才离虎口又入狼窝？
而且这么多年了微软阵营的开发者应该都知道上游对坚持技术方向的软弱性和自己选择跟微软走的沉没成本。看这堆特性刷版本号的敏捷套路玩多了，越来越多的 Java 开发者即便不满，也都不愿意上车了。
要知道大多数开发者其实日常是摸不到 JVM/CLR 之类垃圾在哪的，所以深刻体会到 Java 的烂以后，这年头 Java 开发者流行跳其它 JVM 语言，转型失败风险小反复横跳难度低，哪像你.NET 看起来那么 49 年入国军的？

别的用户转.NET 么，生态位问题，不会是主流路径。毕竟历史上你.NET 的中坚力量 C#造出来先天就是怼 Java 的（.NET 本质是召唤 COM 加成，只要接受微软全家桶能受得了 0x800 稀里哗啦的 HRESULT ，不用白不用），所以吃不死 Java 用户，也没什么盼头了。
别的比如搞 C++的，因为嫌弃语言用起来麻烦跳 Rust 之类还算正常，但跳.NET 的理由基本只会是被迫写 UI 然后还只需要应付 Windows ，而不是说 C#之类真比 C++用起来舒服到哪去了（光一个 using 的缩进就够欠扁了）。

弟弟 V9 第三次碎屏（多手贱了一次内屏又出问题）第二次电源键失灵（官方售后还订不到货），所以干脆就上了个红魔 7P 。
确实还是很多不爽（所以我一个官解 BL 的弟弟 V9 能撑那么多年），但是，禁不住人家大啊（ 18G+1T ，反正比我 SB2 大
8Gen1 是真的……但一时也没得选，希望风扇能压住吧。重量勉强能接受，系统优化续航不指望了（这机器快充功率属实吓人，应该能减少点影响）。
看在 3.5mm 耳机孔的份上没 IP68 就忍了。
摄像正好没什么需求，而且真全面屏算是治好一部分强迫症了。
刷系统反而是小问题，只要不是三星那种 eFuse 或者不给解 BL 的（直接不考虑）。反正不指望刷公版 Linux 了。

@learningman 那种一般就不会叫虚拟内存。
实际能替换的，基本就只限于光栅图缓冲区这种，也不是 placement new ，还要有 swap buffer 的真 IO 。一些看大图的软件就有这种机制，上面也有人提。但看 OP 的描述，加载都已经分块了，到后面显示渲染还不够用，那这个 swap 就不是重新复制缓冲区那么简单，横竖还得改渲染算法在光栅化之前做文章。这就跟虚拟内存更没共同点了。

@learningman 你想少了。虚存是带地址翻译的，没硬件和系统支持下，首先得把访存的寻址都替换掉，原则上需要多出至少一倍指令。这就还是有类似 MPU 之类的硬件中断的情况，纯软件实现你得模拟缺页中断，基本就是把非交换访存全替换为模拟中断例程的函数调用。要实现这个基本得改编译器（从前端把*替换成 builtin 开始，只改后端还不够）。
直接 placement new 不能改善同时占用的问题。placement new 要求有已经分配好空间随时能用的指针，都没法用 fancy pointer （而且现在标准库的 allocator model 能分配的还要求在地址空间内连续）。

@BeyondBouds 你这什么屑产品经理还管那么多？要空间不够用负责帮用户加内存么？
@learningman 你清楚在说什么么。
在没有 MMU 或者没有系统特权的情况下实现虚存跟实现个没硬件加速的系统级虚拟机的工作差不多少。（虽然 iOS 不管 ISA 细节横竖都禁止加速了。）

@RobberPhex @dreamramon @loryyang @byte10

提到的一些通病比这里说的原始问题更有毛病得多。

栈作为活动记录的一种实现，本来就用于隐藏过程运行时状态的实现细节。只有直接能在程序中显式访问活动记录的语言（比如至少得有 first-class one-shot continuation ），这种东西才配被要求是和程序员交互的标配。
说白了，在抽象能力弱鸡的语言里没事依赖栈帧是一种习惯性纵容实现泄露抽象的病。
特别是要知道 Java 不光不支持 continuation capture ，甚至连 proper tail call 都没有……设计 JVM 的丈育还用 stack inspection 当挡箭牌，结果差不多被正面打脸： https://stackoverflow.com/a/5097402
退一步讲，真是想要照顾调试体验，又不是 C 这种滥依赖 ABI 兼容的历史包袱，这么多年了连个 shadow stack 都不会实现的弟弟怎么好意思变成工业主流的？

算了，还是先停止把 stack 叫做什么劳什子“堆栈”开始吧。

（反思为什么 NPE PTSD 以及 optional 实质套娃的问题就不提了，本质算不上 Java 特色，虽然这年头也快成了 Java 特供问题了。）

@paopjian 使劲儿时间膨胀完事……

？现在 Java 普及了 Babel 类似物了么？不卡源语言版本的？
（要能用 transpiler 一般也是全体 JVM 语言，用不着特指 Java 。）

这类古董挺多了……
收藏夹里正好也有个，也是搜狐的，比 9L 的早：
http://news.sohu.com/01/18/news206991801.shtml
以前曾经经常引用（

@ryd994 “脱库的问题与是否进行客户端 hash 无关”，这显示出你的理解的偏差。
虽然不直接相关，但脱库得到的内容的使用方式可以类似，使用 hash 的动机也一致。
而这种敏感数据除了脱库还可以通过劫持客户端通信来获取（于是你说的对策反而不够用）。即便没像服务器被攻击那么瞩目；就受害者看，威力一点都不小。

对抗这种攻击，要做到攻击者本人通过唯密文攻击的方式无法分辨出敏感数据中可能带有的感兴趣的特征，至少不能一眼认出来。
至于是不是正经的加密，其实相对无关紧要，所以一个像样的 hash 都行。（当然，得别被随便能反查。）
若有这种客户端 hash ，攻击者要实现相同的效果，除非强行爆破 hash ，基本还需要多攻破客户端系统基础设施。
因为系统厂商普遍盯得比较紧，后者一般比单纯让 TLS 失效（各种意义上）难得多，或者至少没法长期利用。
使用非公开 hash 算法时，强行爆破成本很难预期。
首先，若攻击者无法获得程序取得其中的算法，这就无解。（当然，网站就弃疗好了，毕竟浏览器属于公共白嫖设施。）而想要通过攻击得到能分析的样本，也需攻破基础设施。
虽然要强行作为加密系统，这明显不符合 Kerckhoffs 原则而影响适用性，但是：
(1)说了用 hash 就强调不需要加密，虽然其实加密也能用，但拿来恶心攻击者这就杀鸡用牛刀了；
(2)让攻击者知难而退这种更普遍的方法论甚至就不算是密码学的原理；反倒是使安全性和加密信道的密码学强度正相关的实践，只是其中的一种特例罢了。
其次，即便有样本能逆向，非公开算法自动化手段相比查表之类可以说是极弱，光分析客户端行为就够普通攻击者喝一壶的了。
再退一步，能逆向成功甚至能直接看源码，之后怎么破还得密码分析，也根本没通解。

硬从理论角度讲，这里能保障的安全性的定义根本不同：系统的安全性不是以存在确定明文（以及加密和解密）作为前提来定义的密码系统的保密性（不论是信息论安全性还是计算安全性），而是使从信息中提取任何攻击者感兴趣的函数的计算开销的度量（若资源确定，也可以用成功概率）。
一些假设：(1)攻击成功前攻击者无法预先给出区分是否有兴趣（或度量利用价值）的算法；(2)（有兴趣的信息足够少）任意不依赖内容的选取子集符合兴趣的方法的概率现实地任意接近于 0 ；(3)人基于现实不可描述的、依赖个体对敏感信息特征识别的经验，有一定概率（使用未指定的未知算法）超越任意机器提取信息的能力，特别地，蕴含筛选出提高成功率的正确决策方法。
基于(1)和(2)，任何现有机器在都不能分辨被 hash 隐藏的特征是否符合攻击者的兴趣（否则这机器得能自主定义什么叫兴趣判断什么值得继续爆破，基本就是强 AI 了）；于是，结合(3)，确定时间内，攻击的成功严格依赖于人。
那么 hash 的作用就是专门欺负人：消除特征，添加噪音，让人肉攻击者的经验失效，概率无限接近于 0 ，成功提取信息的代价任意地大，从而实现不可攻击。

是不是值得保障这种安全是另一回事，但这种安全性的现实存在是确定的。（并且很容易有木桶效应。）

@FrankHB 注：我不清楚 21L“包括了键盘序列加生日和手机号等常见密码组合”具体是指什么，但是要全覆盖，光是手机号（杠一点，其实还有国际区号）都有些难度，更不用说“特定前缀+手机号+特定后缀”的组合了。注意这些 pattern 是可以每个凭据都有变化的，没法大规模自动撞库。

@ryd994 要防止撞库的自动化攻击只要避免完全一样的口令即可。能反查的仅限全文匹配的没加盐的。
而且，规模受限；比如生日这个空间不够大够放表里，那么手机号呢？

另一方面，实践中用户可能使用的简单生成策略，比如把相对容易反查的数据和某个无法预测但是攻击者可以人工推断的前后缀串接，就能让反查失效。这个也算是盐，不过是加在了用户的脑子里罢了。
如果没 hash ，这仍然是一种明显的复用而会受到威胁；不巧的是，这种编码方式实际还真是挺顶用的，最起码对大多数人来讲比全随机串好记得多。

用户为什么要复用密码？因为实现成本低。这又是因为，密码这种形式，要求用户自己实现密钥的重现。
只要 UI 上需要用户日常记忆的密码（而不是你说的所谓“高安全的鉴权方式”）的情况普遍存在，“复用”基本就是刚需。但是想要高安全的鉴权方式替代，如何普及？多出来的成本你搞定？
所以说，问题的根源并非鉴权方式不够安全，而是欠缺鉴权的服务等级，无法落实对合适的路径使用合适的鉴权机制。对不重要的账户，就应该避免要求高成本的鉴权方式，而不是逼着用户平摊鉴权成本自己搭建可能对某几个关键路径不够安全的服务。
但不重要也只是相对而言，并不是说无所谓了。所以即便有智能卡的情形你能说 hash 没用，没智能卡就弃疗的思路显然是不对的。这种情况下，有没有多一层 hash ，安全性不可能一样。
特别地，考虑到这样做的主要理由正是应付直接推高用户记忆成本的被大量滥用的密钥策略，你要是想甩锅给用户这样就是安全习惯不好，是用户的错，此路更加不通。

而如果真要提高安全性，那么只有方案也是不够的。现有基础设施无法提供的安全机制的实现，服务方也应该一并提供——比如银行可以提供 USB key ，但不应该把设计甩给用户让用户自己造一个，造不出来就后果自负。
所以有没有 hash 不可忽视的情形下，hash 应该由服务方提供而非用户自己变通。

至于“hash 的结果成为了实质上的密码”，只要被截获的信息不能被反查出明显特征，这就不是用户需要关心的。服务器用哪个 hash 都不提高用户保障安全性的成本，这才是所谓的“一样”。因为成本原因，智能卡可以没有，这种“一样”反倒是优先该有的。

。。。对不起，看到“小公举”忍不住喷射早餐到屏幕上了。。

这种东西，有确保执行力专家的就直接让专家起草，否则放 wiki 页面找个召集人让项目成员一起写，免得规范没讲清楚，style 上就先扯皮了。
负责代码层次上具体规范和往上提供工程支持明显是两码事，职责得分清。

主流大厂也不见得质量好哪去，说好听点是妥协，直说就是菜。

比如，Google C++ Style （官方叫 Guideline ）这种几乎每一条都有槽点到跟 anti pattern 都没差多少的，如果看不出来问题，那就足够说明 C++不怎么熟悉，不能胜任一般意义的起草规范的工作。
其实我是觉得至少要能发现 GSL 的大部分缺点才算得上是规范管理专家的入门水平。Google 那种明显属于怂了不合格；具体点，如禁用异常，理由是不信大部分员工会用好……（这么基础的东西，啧啧）。

这种规范，有时候明文还不如事实标准慢慢磨（ copyright notice 之类法务要求的另说）。

而要帮助提供工具，设计流程之类，自己怎么方便怎么发挥，就没这个限制。

。。。软考中级基本就是氵本科没毕业大都混过的水平，也没什么很超越通识的题，随便百度之类的花一小时摸清楚大概范围就差不多了。而且出题的水平就是菜，我当年笔试做完题为了避免太快交卷还把题重新过了几遍数（腹）落（诽）出题人显示在题干的技术错误来磨时间。
还是说这几年难度突然增加了……？
另外中级跟高级其实没啥可比性，后者要写作文，有点考公的味儿。

@ryd994 你的分析有个明显的缺陷：完全假定对凭据的攻击是机器进行的。然而攻击的原理并不一定是密码学，至少还可能是社会工程学。这包括人可读而机器不可读的口令——一个常见的应用是，根据“密码”中包含的 pattern 猜测用户设置口令的偏好（比如是否包含某种明显像是生日之类的个人可识别信息），缩小相关的其它需要碰撞的敏感信息的解空间，显著优化攻击效率。而一旦经过任何一个常规的 hash ，甚至不需要 salt ，这种 pattern 就被完全破坏，也就直接报销了一个重要的攻击向量。

@LotusChuan 这是公共空间的讨论。回复框边“请尽量……能够对 [别人] 有帮助”未必要包含你。重复强调对“你”没意义，才对谁更没意义。但为了让你能认识到，这个回复我先假定当作有意义。

我自忖我前面的回复全是展开的技术话题，倒是你的回复里都有断片得都出戏而莫名其妙的。所谓“拿去写自己的博客会好一点”，言下之意，个人观点不该在这发……那 OP 发这主题算啥？现在又来个“答非所问”，“问”是什么？ OP 的题是“有感”，压根没问。这里就没人在问。所谓的“答”就是对回复的观点评价，是主题讨论的间接展开，也没你的评论更跑题。“不信的话……多少人回你呢”就更奇葩了，照这逻辑，你第一个提到 K&R 的回复要不是我回还就没意义了？

奉劝停止狡辩；为减少跑题影响，压缩对你多得离谱的理解偏差和显摆不理解的回复，还是得费劲。