还是见得少，Oracle 的一部分、Mysql/MariaDB 、Handop 体系、Apache Storm 等等工具类的应用，这些也是 Java 开发的，他们不用 Spring 。只能说业务类或信息处理类的应用（以前还有专有名词 Java EE——Java 企业级应用），绝大部分都是用 Spring 体系的。

@codergrowing #15 可能我记错了，不过 Spring Boot 之后，Spring MVC 部分推荐的都是通过方法参数注入，已经基本不用成员变量注入了，这种注入单例非单例都没区别。一般来说，从 Struts2 之后，控制器部分都是单例的，可能 Spring MVC 发现没有成员变量注入之后会自动优化成单例模式。

你的第二次使用已经正确了：注入到 Controller ，再传递给 Service 。Controller 是非单例的有状态 Bean ，可以注入 HttpServletResponse 。 @twofox

其实对于 HttpServletResponse 这种跟当前请求绑定的对象，最好全程通过方法参数注入，不要将他注入到类的成员变量上。Spring MVC 中，如果把 HttpServletResponse 作为 Controller 的方法的参数，不需要加 Autowired 它都是自动注入的。

HttpServletResponse 是绑定当前连接的有状态对象，Service 通常是无状态 Bean ，Controller 通常是（ Spring MVC 就绝对是）有状态 Bean ，因此，HttpServletResponse 注入 Controller （的成员）没问题，注入 Service （的成员）会产生严重问题。

你如果注入 Service ，那么第一个请求来了会把当前请求的 HttpServletResponse 注入单例的 Service 。单例的 Service 中的这个成员，一旦注入过就不会再重新注入了，以后所有的请求调用的 Service ，使用的都是第一个请求的 HttpServletResponse 。这个 HttpServletResponse 对象本身因为还被引用着不会被回收，但它里面引用的其他对象，会在第一个请求完成之后就销毁，于是后面就会出现 NullPointException 。


最后说一点，exportSevice.export(params, response) 这样的方法，即把依赖对象通过方法参数传入，不是用 Spring 实现的依赖注入，但它也是依赖注入。

@Kawa 你对跨平台（或者操作系统适配）、UWP （通用应用）、客户端的理解都有偏差，然而最直接的还是太迷信 go 。go 最开始以及现在一直是用来替代 C 的，也许还能替代 C++，这意味着它跟 C/C++一样主要是用来适配 Windows 、Linux 、Unix 等传统操作系统的，不适配 IOS 、Android 、WebOS 、Win10 mobile 这样的新型移动操作系统（并不是不能适配，而是生态不在这里很少有人去吃力不讨好的搞底层适配库）。

win10 mobile 跟 win10 只是内核一样，整体上还是俩类型的操作系统。kindle 和早期 Android 系统，你解锁了之后就是个 Linux 。

其实你有更好的方案：PWA 。然后你就会发现真正的难点是跟 QQ 服务器做沟通——理论上来说，任何接入 QQ 服务器的第三方，都要被南山法院锤。

@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 编译，对性能影响不是严重的级别，能解决掉是好，但是为了开发便利性不解决也可用。