@ql562482472 主要是后者。

因为面向行业信息化的软件系统里，业务功能和基础设施功能可以看作是两个不同的领域。既然是不同领域，就有不同的知识模型。不排除做行业信息化的公司里也有相当的专家熟悉基础设施领域的知识，但因为做行业信息化的公司其核心价值是解决客户的业务发展需求，所以首要的关注点、投入最大技术人力成本的方向是实现业务功能。而基础设施领域里则有更擅长的参与者。对于做行业信息化的公司来讲，要业务功能开发人员兼顾基础设施开发，实际上是逆分工而行，出力不讨好。尤其是，相当一大部分程序员是没有能力写高质量的基础设施的。

给你举个我遇到的真实例子。上级信息主管部门发来安全通告，某个业务系统的后台管理模使用的开源组件老版本爆出 CVE ，要求限期内处理。问供应商，答曰我们用的这个业务系统已经是老版本了，他们公司现在主推新版，老版不再更新，而且那个开源组件直接换成新版的可能不兼容……可以给我们安装新版本的业务系统并迁移数据，不额外收钱。但是新版本安装实施时间挺长的，超过处理期限了。我说你们老系统的 web server 是 IIS 这种通用的玩意，你后台管理模块路径是确定的，在 IIS 里配一个 ACL 规则，先把后台管理限制在我们单位的 IP 范围内，对最终用户还是全部开放，这样不行么？对方说，加上限制 IP 的功能要排期做开发，旧版系统他们不改动了。我说这是运维手段解决问题，不需要你们程序员改代码。对方还是坚持这是功能变更。吵了好几轮，最终还是我放弃了。先停掉有问题的旧版系统再说。

举这个例子是想说明，像分模块做 IP ACL 之类的功能，其实是和客户的“业务”功能没有关系的基础设施功能。做基础设施软件的开发商（不论是 IIS 开发者微软这种真的“商”，还是免费的 Apache 、Nginx ）早就把基础设施功能玩得溜溜转，你能想到的基础设施功能需求很可能就是用现成软件做做配置就好了，你没想到的，他们也都早替你想到了。而他们在基础设施领域的经验、技术能力、成本投入，都不是做业务系统的开发商在完成客户业务功能开发这一核心价值之外顺便来开发基础设施功能所能比拟的。善用成熟的第三方基础设施软件，善用运维手段解决非业务方面的功能需求，这在某种意义上也是解耦，不次于“开发”中所做的解耦。尤其是复杂的软件系统会跨越不同编程语言、运行在不同进程甚至不同机器上，用好成熟基础设施，往往能比业务纯程们在写业务功能之余自己去造基础设施的轮子，甚至比起用现成的基础设施库或框架嵌到自己写的程序里调用，都有更好的收效。据说 Spring Boot 时代，主流的做法是构建一个巨大的 jar 用 java 命令启动，不提倡构建成 war 放到 tomcat 之类容器里运行。这种做法当然有其应用场合和原因。但是我想问一下，从来不碰生产环境运维配置的纯程们，是否知道只靠修改 tomcat 的 server.conf 、不自己写代码，能对 tomcat 的行为做多少控制，能解决多少你们第一反应是写代码实现的非业务功能需求？这些如果都靠业务纯程们来写，要多少工作量？代码质量如何，是否能担得起“基础设施”的质量要求？即使不自己写，靠项目里 embed 一个 tomcat 或者 jetty 的核心包，如果要达到打包好的 tomcat/jetty 的可配置程度，你又要在自己的项目里写多少代码来处理配置？