@Ds97 #19 国外手机号上 Google Recaptcha 或者其他机器人识别，国内手机号用他说的微信那个方法。

逐步骤监控变量的值还有办法，但是你想在值变化时做自动处理（打印些信息），你不动代码是不行的。这是个 public 成员，可以直接赋值，切面都加不上。

还是想办法做断点调试吧，一步一步的查看值的变化。当然你不能直接在线上搞远程调试，尤其是你还想长时间的监控。你这个是公共静态变量，一个断点暂停就可能让整个系统崩溃。能在本地环境复现问题然后在本地断点调试是最好的，如果不能或者不好复现，那么只能逐行看代码了。

Eclipse 有几个功能可以帮助你找到哪个代码会修改这个值：右键变量然后选择“call hierarchy”；选中变量再 Ctrl+H ，然后可以查找所有引用这个变量的地方。

UWP 的基准就是 C#+Xamarin ，你这一不想用 C#二想绕过 Xamarin 直接启 exe ，那搞出来的只能是 Win32 转制 UWP （只能在 PC 端使用的假 UPW ）。

漏洞是漏洞，BUG 是 BUG ，这俩本来就不一样。

此外 Spring 的跟踪系统，不管是以前的 JIRA 还是现在的 Github ISSUE ，都是跟踪 ISSUE 而非 BUG ，这本是就是不把 BUG 当负面性的跟踪系统。“零 BUG”是部分国人的专属态度，不管是 ISO ，还是 CMMI ，还是纯敏捷，都不要求这个态度。

终审会员，要么等于没用，要么等于要跑路，这事放到哪里都一样，最著名的就是 P 站。

说点题外话，好得产品经理，应该引导客户把沙雕需求变成好需求。如楼主的需求，对于客户来说，PAD/PC/MAC/WEB 编辑查看+手机仅查看，是比手机啥都干，更好的工作方式。如果实在要手机也编辑，那么花钱买个好的引擎，是比让上层 APP 做优化，更有效的实现方式。

Stream 及 Lambda 表达式的第一优点就是代码简洁，这跟 code review 是正相关，不是互斥的。

不过 Lambda 表达式能无缝转接，Stream 不能。Stream 使用的是数据流逻辑，跟传统的“判断、循环……”逻辑有区别，转换过去需要学习。但是这个学习成本不大，而且如果是数据结构 /算法已经很溜的，早就回了压根不用学。大佬刚开始不让用，可能还是要考虑团队管理，大佬要是一直不让用，那他 100%是假大佬。

@ruixue 我接着看了你后面的对话，发现你是一种啥都往最好做的想法，俗称“烂好人”。这个想法在事情小的时候是真好人。但是，哪怕是非常小的成本，也是会富集的，当事情大的时候，啥都想做好就会变成啥都做不好，成了烂好人。客户端哈希或者加密对于小系统（或者个人）来说确实成本很微小，但是对于几十甚至几百人开发的大系统，成本富集到管理者那里就会很庞大。这个时候管理者就要做均衡了，极为重要的系统不止要做客户端密码哈希，客户端非对称加密都要上，甚至可能还要上物理证书（俗称的加密狗），但是面向大众用户的客户端，上个 HTTPS 就够了，哈希都不要做。

现在 Spring Boot 也是滚动更新，J9 以上也是滚动更新。凡是滚动更新，不出漏洞才不正常。当然，对于 Spring Boot ，以及所有库，的滚动更新，如果你写好写全了单元测试代码（相比于只编码，工作量最少加两倍），那你只要一直用最新稳定版本就没事了，漏洞顺手就改，连手动测试都不需要。以上仅限于上层应用框架，JKD 这种底层基础设施，能不升级就别升级，尤其是 J9 以后那狗日的不考虑向后兼容性的滚动升级。

@ruixue #7 一、CDN 不能直接获取到明文，除非你让它获取。二、服务器记录日志不脱敏，是程序设计问题，并且在开发期就可用解决，那这个就不能用来作为运行期安全措施的论据。客户端加密或者 hash ，那是肯定有意义的，但是要不要实施这种措施，是要跟成本做对比的。当前，密码泄露的风险，真得没有客户端 hash 密码造成开发测试的不方便的成本大（服务器密文保存密码更多的是防止撞库，这也能解释为什么服务器不能只是单纯的 hash 密码，而必须先加盐再散列）。

@dLvsYgJ8fiP8TGYU 只有超高安全级别要求才会在客户端加密密码，通常都是：客户端和网络传输明文，服务器端存储散列码（密文），通过 HTTTPS 来保证网络传输阶段不被窃取。此外，就算你这个系统的安全级别是要求客户端加密密码，对于没法升级的旧系统，也得允许降级成客户端不加密的方式。

面向对象编程第一个解决的问题：让开发类库的人和使用类库的人可以分开。开发 Spring ，和使用 Spring 开发业务，一个是开发类库，一个是使用类库开发业务，你不能那一个标准去看源码。

你说的 2 ，其实就是 1 ，只不过是把解决冲突的操作从本地搬到远程而已。2 发生冲突的时候，你并不是必须用远程仓库的工具，还可以本地在 feture 解决冲突并推送之后，再重新执行 MR/PR 的合并。MR/PR 开启之后，是可以继续提交的。

如果你执行的是全 merge ，并没有 rebase 的话，2 会更省事点。

如果是用 rebase 来搞准线性历史的话，要用 1 的方式。

这问题的答案，不取决于技术或任何客观性的东西，完全取决于你的领导和公司的风格。要是“零 BUG”风格，你不管选哪个最后都要背锅。

正常情况下，都是问题越早发现越好的。CMMI 、ISO 体系（不是国内那种拿到资质就不再遵守的假体系），以及各大开源框架体系，选择的是前者，去看看开源框架的 Issue 库和版本发布文档就能看出来。

对于 JPA 、Hibernate ，或者任何 DDD 模型来说，所有关联对象都是要（立刻或者延迟）全部加载进内存的，所以不能随意设计关联，要在业务上的关联和性能上的伸缩性之间做平衡。

其他备注：不要太过于在意 N+1 问题，N+1 虽然是 N+1 次查询，但是实际上也就两次 SQL 编译，对性能影响不是严重的级别，能解决掉是好，但是为了开发便利性不解决也可用。

虽然都是基于 Java ，但面向前端 UI 的生态，跟面向后端的生态之间的区别，要比跨语言还大。kotlin 毕竟是从 Android 出发的，后端一时半会不会用。

还有另一方面，Java 太大了，Android 部分，和 Web 后端部分，只是最流行的（或者说搜索引擎上搜索最多的），但可能连 Java 总生态的 1/3 范围都没占到。（比如说，Mysql 数据库、Oracle 数据库中的 Java 部分、Hadoop 、Storm ，这些都是 Java 开发的，即没有用 kotlin 也没有用 spring 。）这直接导致除了基本 JDK ，很难有框架能一统天下。就是 JDK ，因为 JCP 基本上被 Oracle 独家控制了，也快分裂成 JDK-current 跟 JDK8 两套了。

@nevin47 #19 我建议你还是先去仔细区分下 CPU 架构 /指令集，操作系统，虚拟化，容器化的区别。

@nevin47 #10 不管是容器，还是分区，这都是在不改变 CPU 架构的情况下搞的。垮了 CPU 架构，因为指令集不同，必须要搞虚拟化或者指令模拟。跨架构虚拟化肯定损耗很大性能，指令模拟需要很大的投入成本，做得要不好还不如虚拟化。说个简单的例子，windows 下的 docker ，是要先用 hyper-v 搞个 linux 虚拟机的，这还只是跨系统没跨 CPU 架构。

POP3 确定没推送，IMAP 和 Exchange 貌似也没推送（ gmail 跟 outlook.com 貌似是用额外服务做得推送）。电脑上的传统邮箱客户端都是定时拉取邮件的。IOS 系统没有单项服务的后台，你得想其他办法了

别的不知道，但是如果不一样的话，你不管是上 docker 还是上虚拟机都没用，跨架构的虚拟化，性能损耗非常大。