后台开发聊到 Java基本绕不开两个词SSM 和 Spring Boot。我面试别人的时候几乎每一轮都会遇到类似的情况——“简历上写着熟悉 SSM也写着熟悉 Spring Boot”但当我把问题变成“这俩到底什么关系、有什么区别”时很多人会犹豫然后抛出一句“Boot 比 SSM 新Boot 更好用”。这句话不算错但经不起追问。因为它俩根本不是同一维度的东西放在一起比就像在问“汽车零部件组合方案”和“整车车间”哪个更好。今天这篇就不端教科书了我把这几年实际带项目、写代码、调依赖时踩过的坑和想明白的事情都放在一起争取一篇让你把这件事看通透。1. 先搞清楚一件事SSM 和 Spring Boot 根本不是“同辈”1.1 SSM 其实是三件套不是单一框架很多人一说到 SSM默认它是一个框架其实不是。SSM 是三个框架的组合Spring、SpringMVC、MyBatis。Spring 管对象和依赖注入SpringMVC 管 HTTP 请求到后端方法的映射MyBatis 管数据库 SQL 和结果的映射。它们各管一段组合起来之后才能完成一个典型的 Web 后端项目从前端请求到数据库落盘的完整闭环。这个组合出现在 Spring Boot 流行之前。再往前数还有个更老的组合叫 SSHStruts2 Hibernate Spring。Hibernate 当年是“全自动 ORM”的代表你几乎不写 SQL它帮你生成 SQL但问题也出在这表结构稍微复杂一点、SQL 需要手工优化时Hibernate 的改造成本极高。MyBatis 本质上是个半自动的持久层框架SQL 还是你自己写的框架只负责把参数映射进 SQL、把查询结果映射成对象这就让开发者保留了极大的 SQL 控制力。所以“SSM 火过”不是偶然。它把 Spring 的 IoC/AOP 能力、SpringMVC 的轻量 Web 分层、MyBatis 的灵活 SQL 控制这三样优势都占了在很长一段时间里是 Java 后端岗位 JD 里出现频率最高的技能要求。1.2 Spring Boot 是脚手架也是预组装车间Spring Boot 则完全是另一个角色的东西。它不是重新写了一套 Web 框架也不是替换 SpringMVC 的替代品它是“用来快速搭建 Spring 生态项目”的脚手架。官方定义喜欢说“约定优于配置”翻译成大白话就是大部分你懒得写、写起来又容易出错的配置我提前给你准备好了你只要按我的约定放东西项目就能跑起来。我经常用“汽车组装”来打比方。SSM 时代的开发方式相当于把你叫到车间里发动机、变速箱、车架、螺丝一个一个发给你你得自己看图纸组装装完还得自己检查有没有漏螺丝Spring Boot 就像把一辆半成品车给你核心底盘已经组装好了你只需要接上自己的业务模块改一改参数就能开上路。这里的关键是Spring Boot 并没有发明“新的车”它仍然在用 Spring 的引擎、SpringMVC 的方向盘、MyBatis 的轮子。它改变的是“交付形态”。你看到的“boot 项目里只有一个 main 方法就能起服务”其实是它把原来需要在 XML 里声明的一大堆东西在启动阶段自动配置掉了。1.3 演进线从 SSH 到 SSM再到 Boot理清历史线会更容易理解现在的局面。早期企业项目很多用 SSH后来因为 Hibernate 太重、Struts2 漏洞频出大家逐渐转向更轻的 SSM。这个阶段开发者的痛苦在于“整合的成本”Spring 配置、SpringMVC 配置、MyBatis 配置、事务配置、各种 jar 包版本冲突全都要人为处理。一个项目能启动成功是开局胜利。Spring Boot 在这个背景下出现并不是要推翻 Spring而是要把“整合”这个体力活干掉。它用 starter 依赖统一了 jar 包版本用自动配置把常见的 SpringMVC、事务、数据源、Jackson 序列化等配置在内存里替你完成。于是整个 Java 后端生态的项目形态从“一套复杂的 XML 工程”变成了“一个带启动类的简易工程”。所以SSM 和 Spring Boot 是先后出现的但出现顺序不代表替代关系。SSM 是“开发组合”Spring Boot 是“让这类组合快速生效的基础设施”。想真正理解 Spring Boot最好是先亲手整合过一次 SSM——这就像你先学会烧菜再理解半成品净菜为什么省时间。2. 区别与联系它们之间的血缘关系比我预想的还要深2.1 联系容器没变注解没变干活的人也没变先说联系这也是多数人在概念上容易糊涂的地方。你随便打开一个 Spring Boot 项目会看到满屏的Controller、Service、Autowired、Transactional、Mapper。这些注解和 SSM 项目里的用法几乎一模一样。原因是Spring Boot 的 web 层在底层依然用的 SpringMVCIoC 容器依然在运行 Spring FrameworkORM 层依然可以挂载 MyBatis。换句话说你在 SSM 里学的“Spring 容器管理 Bean 的生命周期”“AOP 切面怎么织入事务”在 Spring Boot 里一样适用。我遇到过不少刚入职的同事以为学了 Boot 就可以彻底忽略 SSM结果排查问题时连DispatcherServlet怎么初始化、ContextLoaderListener加载了哪个父容器都摸不着头。这些概念在 Boot 里虽然被藏起来了但它们始终存在。面试官问“Spring Boot 自动配置原理”骨子里就是在问“Spring 的 BeanFactory 和配置机制”。2.2 区别拼积木和吃预制菜联系讲完区别就清晰了。我习惯用一张表记住两者在落地时的核心差异。对比维度SSM 时代Spring Boot 时代依赖管理手工维护所有 jar 版本冲突自己解决starter 统一管理BOM 帮你锁版本配置方式多个 XML properties甚至还有 mapper 配置application.yml 自动配置 条件注解Web 容器外置 Tomcat打包成 war 丢进 webapps内嵌 Tomcat/Jetty打包成 jar 直接 java -jar项目结构src/main/webapp/WEB-INFweb.xml 是灵魂无 webappmain 方法 内嵌容器日常开发效率每写一个模块都要想着往 XML 里加配置注解 starter 一把梭少量配置即可适合场景老项目维护、需要极端控制 XML 的场景新项目、微服务、快速交付、云原生这张表里最核心的一项其实是“依赖管理”。SSM 时代我印象最深的是动辄几十个 jar 的 pomSpring 版本和 MyBatis 版本不兼容、Jackson 版本互相覆盖这种问题排查起来非常磨人。Spring Boot 的 starter 机制把常见依赖组团管理spring-boot-dependencies帮所有关联依赖选好兼容版本大多数情况下你不用再手动指定版本从源头减少了一类问题。2.3 面试送分题Spring Boot 是不是 SSM 的替代品这个问题正确答案是“不是替代而是进化和封装”。Spring Boot 替代的不是 Spring、不是 SpringMVC、也不是 MyBatis它替代的是“人为把这些框架整合起来的过程”。你可以做一个 Spring Boot 项目然后在里面完整地使用 SpringMVC MyBatis这就是现代版的 SSM只是不再需要你写SqlMapConfig.xml和spring-mvc.xml。所以面试时更稳的说法是SSM 是“Spring SpringMVC MyBatis 的组合方案”Spring Boot 是“让 Spring 生态项目快速落地的基础框架”。Spring Boot 能包含 SSM 的组件SSM 也可以用 Spring Boot 的方式重新组织。Boot 没有让 SSM 过时它只是让 SSM 的组装过程消失了。我自己招人时其实更看重“会不会从 Boot 反推出 SSM 的配置”。因为如果你能猜出 Boot 自动配置在背后做了什么出了问题就不会只靠百度拷配置而是能顺着条件注解和 starter 源码找到真正的解法。3. 从 SSM 迁移到 Spring Boot真正要改的是这三处3.1 项目结构webapp 消失了但分包思路还在以前建一个 SSM 项目标准结构大概是这样src/main/java放代码src/main/resources放 spring 配置和 mapper 映射文件src/main/webapp放前端页面和 web.xml。打包出来是一个 war丢到 Tomcat 的 webapps 目录下启动容器才能访问。Spring Boot 出来之后项目形态变成了一个“干净的可执行 jar”。你不需要 webapp也不需要 web.xml。前端静态资源放到src/main/resources/static或templates下配置全部收敛到application.yml。主启动类放在根包下默认扫描当前类所在包及子包这意味着你的 Controller、Service、Mapper 只要都放在主类所在包的子树内就都能被扫描到。有开发经验的人很快会发现分包思路其实没变。我还是习惯按controller/service/mapper/entity/common/config这类结构分包。Boot 削掉的是 web 容器层面的复杂度而不是业务代码的组织方式。如果你从 SSM 项目迁移过来建议第一步先按 Boot 标准结构建好空壳再把原来按功能分包好的 Java 类搬进去风险最低。3.2 依赖管理从手写 jar 到 starter 闭环迁移时最舒服的变化是依赖。SSM 的 pom 通常长这样Spring Core、Spring WebMVC、MyBatis、MyBatis-Spring、MySQL Connector、Druid、Jackson每一个都要你自己指定版本。版本选错了运行期各种 500 和 NoSuchMethodError。Spring Boot 里一切从 starter 开始。比如要做一个 Web MVC 项目引入一个spring-boot-starter-web就内置了 SpringMVC、内嵌 Tomcat、Jackson、Validation 等常用依赖要做数据访问引入mybatis-spring-boot-starter它会自动引入 Spring Boot 数据访问相关机制和 MyBatis 的集成要接入消息队列引入spring-boot-starter-activemq连接工厂和 JmsTemplate 就自动配好了。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.x/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version3.0.3/version /dependency /dependencies注意别小看这个parent它里面通过 dependencyManagement 把整个 Spring Boot 生态的常用依赖版本都锁好了。所以日常开发你不写版本号反而更安全。如果某个第三方 starter 版本过高导致冲突优先去查它对应 Spring Boot 哪个版本再决定升降级而不是盲目 upgrade。3.3 配置方式一箩筐 XML 浓缩成 application.ymlSSM 时代一套完整配置至少要包含web.xml、spring-context.xml、spring-mvc.xml、mybatis-config.xml、druid.xml有时还有分页插件配置和事务配置。配置多了项目结构重新人上手难。Spring Boot 把这些“通用约定”压缩成默认逻辑。比如 SpringMVC 的DispatcherServlet在 Boot 里自动注册静态资源路径自动映射到/staticJSON 序列化自动配置内嵌容器自动启动。你只需要在application.yml里写自己业务相关的个性化内容。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8 username: root password: 123456 mvc: view: prefix: /templates/ suffix: .html如果迁移过程中遇到“某个配置没有生效”建议先想一个问题Spring Boot 有没有对应的默认配置类比如上传大小限制Boot 里不是去改 Tomcat 的 xml而是配置spring.servlet.multipart.max-file-size。你只要习惯“先按 Boot 的属性名找配置再找对应自动配置类”这个思路基本就能替代记忆几百条 XML 配置的负担。3.4 自定义自动配置看懂 Boot 强大的底层机制很多用 Boot 的人会有种“黑盒恐惧”明明没配什么项目就能跑一旦要定制一点东西就不知道从哪下手。解决这种恐惧的最好办法是亲手写一个最小的自定义自动配置。AutoConfiguration ConditionalOnClass(MyService.class) EnableConfigurationProperties(MyProperties.class) public class MyAutoConfiguration { Bean ConditionalOnMissingBean public MyService myService(MyProperties properties) { return new MyService(properties.getPrefix()); } }再配合src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件把上面的配置类全限定名写进去。这样别人引入你这个模块时只要 classpath 里有MyServiceBoot 就会自动创建对应的 Bean如果用户自己已经定义了同类型 BeanConditionalOnMissingBean又会自动让位保证用户自定义优先。理解到这里你会发现 Boot 的自动配置并不玄乎它只是把 Spring 的Configuration与“条件判断注解”组织在一起写成了一段“按需执行”的代码。SSM 里的DispatcherServlet、SqlSessionFactory、DataSource其实也都是这么被创建的只是你平时看不到。3.5 Spring Boot 版本太高导致迁移失败先别急着回退这几年“版本太高”成了一个高频搜索词。Spring Boot 3.x 是一次比较大的跳跃JDK 强制要求 17包名从javax换成jakarta。很多老 SSM 项目里的代码比如import javax.servlet.http.HttpServletRequest、import javax.sql.DataSource如果直接迁移到 Boot 3.x会直接编译失败。我踩过一次比较深的坑是老项目里用的第三方库还是基于 Boot 2.x 的 starter硬迁到 3.x 之后不仅包名对不上反射代码也拿老方法去调运行期直接抛异常。后来我把策略改成了“先确认依赖的兼容矩阵”而不是一味求新如果项目只是内部系统、JDK 也还能用 8那可以继续停留在 Boot 2.7.x它仍然是稳定版本如果要上新特性、要基于新硬件和 JDK 17 部署那就把代码里的javax.*统一替换成jakarta.*如果依赖的第三方库还没有适配 Boot 3.x更稳妥的做法是检查它的 GitHub 仓库是否发布了新版本或者找替代 starter。版本不是越高越好Spring Boot 的“高版本”是和 JDK、依赖生态绑定的。你没必要为了追新而把整个系统折腾一遍但这个“先查兼容性”的动作比回退版本本身更重要。4. 数据访问层在 Boot 里怎么活MyBatis 仍然是主力4.1 三大数据访问方案怎么选SSM 项目里数据访问基本默认 MyBatis。到了 Spring Boot官方把数据访问也做了自动配置于是你有了三条常见路线JdbcTemplate、Spring Data JPA、MyBatis。JdbcTemplate最原始适合轻量操作、SQL 不多的小项目Spring Data JPA适合标准 CRUD、实体关系比较清晰的场景它能自动生成很多常用查询方法MyBatis则适合 SQL 复杂、优化空间大、团队习惯自己写 SQL 的业务。从我维护过的项目看大多数业务系统最后都落在 MyBatis 上因为它让开发对 SQL 有绝对掌控力也方便 DBA 审查慢查询。Spring Boot 引入 MyBatis 很简单一个mybatis-spring-boot-starter就搞定。它会在容器里自动创建SqlSessionFactory把Mapper接口扫描并注册。老 SSM 项目里的Mapper接口和 XML 文件基本不需要重写只要保证 XML 的 namespace 与接口全限定名一致、ID 与方法名一致就能原封不动搬过来。Mapper public interface UserMapper { User selectById(Param(id) Long id); }select idselectById resultTypecom.example.entity.User select * from user where id #{id} /select更省事的是引入mybatis-plus-boot-starter在 MyBatis 基础上加上单表 CRUD 的封装。毕业设计和中小型企业管理类系统用它开发效率非常高。4.2 数据源与连接池的配置要点数据访问的第一步是数据源。Boot 默认支持 HikariCP不用额外配置连接池。很多公司因为有监控需求也会选择集成 Druid。spring: datasource: hikari: maximum-pool-size: 10 minimum-idle: 5 connection-timeout: 30000如果要用 Druid引入druid-spring-boot-starter并在配置里指定spring.datasource.type或者用 Druid 自己的spring.datasource.druid.*配置节点。注意Boot 的自动配置会优先识别DataSourceProperties中绑定的属性如果你发现本应生效的“连接池初始化大小”没有生效大概率是属性前缀写错了。Druid 在 SSM 里需要写一堆Bean和Filter在 Boot 里也一样能配但属性路径完全不同。实际迁移时最容易出问题的是时区和 SSLMySQL 8 的连接 URL 一定要带serverTimezone或者直接用Asia/Shanghai。我第一次迁移老项目时因为少了时区参数所有时间字段都差了 8 小时排查了一个下午才发现是连接串的问题。这里建议配置useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。4.3 事务和 Mapper 搬过来基本不用伤筋动骨SSM 里最费事的是事务配置在 XML 里配置DataSourceTransactionManager然后配置tx:advice或开启注解驱动。Spring Boot 里只要你的 classpath 里有数据访问相关 starterDataSourceTransactionManager会自动创建Transactional拿来即用。但事务自动配置不等于“事务不会失效”。我在实际项目里遇到过好几次Transactional失效的情况本质都是同一个原因方法被同类内部调用比如this.save()调用同类的另一个Transactional方法或者方法是非 public 的或者是异常被 catch 了没有往外抛。这些失效场景在任何 Spring 项目里都一样和 Boot 无关。多理解一下 Spring AOP 的代理机制比单纯背“为什么”更有用。Mapper 部分同样不用折腾。老的Repository可以留着也可以换成Mapper。在 Boot 中如果扫描包的配置不对mapper 接口可能不会被注册常见表现是启动时提示Invalid bound statement。解决方法是确保MapperScan(basePackages com.example.mapper)指向正确或者让 mapper 接口都放在启动类同级的包下面。5. 实战中高频出现的四个疑难场景5.1 多个 Spring Boot 项目如何做到一次登录全部免登录搜这个问题的场景通常是公司里有好几个后台系统每个都用 Spring Boot员工登录 A 系统后跳到 B 系统还要再输一次账号密码体验很差。这块儿的常用解法有几类最简单的共享方式是 Redis Session 共享。先把spring-session-data-redis引进来然后配置存储类型为 Redisspring: session: store-type: redis redis: host: localhost port: 6379正常情况下Session 默认按服务的 cookie path 隔离。如果你希望多个服务共享同一个 Session ID需要让它们的 cookie path 都设置在同一个域名层级下比如两个子域a.example.com和b.example.com共享 cookie 的Domainexample.com再配合 Redis 统一存储 Session就能实现 A 系统登录后B 系统通过同一个 Session ID 从 Redis 拿到会话数据。更现代一点的方案是“统一登录中心 JWT”。所有系统不直接管理会话登录请求统一发到认证中心认证成功返回一个 token网关或各服务基于 token 解析用户身份。这种方式扩容能力强也适合前后端分离。需要注意的点是JWT 不是“服务端会话”它是无状态的一旦签发就无法主动销毁所以 token 的有效期要设计得短一些配合刷新机制使用。5.2 用宝塔 Docker 部署 Spring Boot 项目的完整思路很多小团队和毕设党会用宝塔面板部署服务。Spring Boot 项目最省心的部署方式就是打成 jar再放到 Docker 里跑。先写一个DockerfileFROM openjdk:17-jdk-slim ENV TZAsia/Shanghai WORKDIR /app COPY target/demo.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]然后在服务器上执行docker build -t demo:v1 . docker run -d -p 8080:8080 \ -e DB_URLjdbc:mysql://host.docker.internal:3306/demo \ -e DB_USERNAMEroot \ -e DB_PASSWORD123456 \ demo:v1这里我踩过的坑是时区。默认容器是 UTC 时间日志打印的时间和本地差 8 小时所以在镜像里设置ENV TZAsia/Shanghai非常有必要。另一个坑是数据库地址容器内不能直接用localhost访问宿主机 MySQLDocker 里要写host.docker.internal或者在 compose 文件里把容器和数据库放进同一个自定义网络用服务名互相访问。宝塔里有很多第三方支持可以直接创建“Docker 项目”把你构建好的镜像填进去映射端口反向代理一配一个 Boot 服务就上线了。注意容器删除后数据会丢MySQL 这类有状态服务尽量别用 Docker 裸容器或者把数据目录挂载到宿主机磁盘。5.3 Spring Boot 集成 ActiveMQ 和 HanLP 分词这类第三方库Spring Boot 集成中间件的核心逻辑永远是“找官方 starter再配属性”。ActiveMQ 是老牌消息队列在 Spring Boot 里集成很方便。spring: activemq: broker-url: tcp://192.168.100.10:61616 user: admin password: admin jms: pub-sub-domain: false引入spring-boot-starter-activemq后直接注入JmsTemplate就能发消息监听时加上JmsListener(destination demo.queue)里面写业务处理逻辑。要注意的是消息可靠性确认模式、重试策略、死信队列这些在 Demo 环境可以不管生产环境一定要提前设计否则消息丢了你连证据都找不到。HanLP 这类分词库集成思路也类似。先把 jar 和词典放到 classpath再封装一个SegmentService对外提供分词方法。Service public class SegmentService { public ListString seg(String text) { return HanLP.segment(text) .stream() .map(term - term.word) .collect(Collectors.toList()); } }HanLP 的坑在于词典加载和线程安全。资料多的时候加载慢建议做成启动时加载的单例服务如果是自定义词典不要把词典路径放在临时目录而是放到镜像内固定路径。分词结果用于搜索建议、内容标签都挺好使但别想着拿它做复杂语法分析。5.4 面试题里翻来覆去问的那几个点面试如果没有专门深挖源码通常会从这几个角度问“Spring Boot 和 Spring 什么关系”回答时落脚在“Boot 是 Spring 的快速开发框架它整合了 Spring 生态而不是替代 Spring”。“什么是自动配置” 回答时可以提到EnableAutoConfiguration、ConditionalOnClass、AutoConfiguration.imports这几个核心概念。“starter 是什么” 除了说依赖管理最好补一句“它不只是 jar 集合还包含了自动配置类”。“Boot 项目目录结构为什么没有 webapp” 因为内嵌容器替代了外置容器静态资源被约定到static目录。“会不会 SSM” 如果你能直接说“SSM 的核心组件在 Boot 里仍然存在Boot 只是把整合流程自动化了”这个回答就高级不少。面试官真正想听的不是你能背出多少概念而是你有没有从“使用者”进化为“理解者”。把 Spring 的容器机制、AOP 代理、自动配置的触发条件想通透面试这一关自然就过了。6. 毕设与真实项目中的选型建议6.1 Vue3 Spring Boot 的毕设项目怎么搭现在毕业设计的标配基本是前后端分离前端 Vue 3后端 Spring Boot。比如一个“全流程进度管理系统”前端负责表单渲染、进度看板、交互反馈后端只提供 RESTful API。后端建议这样分层模块职责common统一返回值、全局异常、通用工具config跨域、拦截器、MyBatis-Plus 配置controller接收参数、校验参数、返回结果service业务逻辑、事务边界mapper数据访问、SQL 映射entity数据库实体dto/vo前端交互对象、展示对象在选 API 风格时别再把页面渲染塞给模板引擎。前端要用Axios调接口后端就用ResultT这种统一包装结构返回。权限控制可以直接用 JWT 拦截器配合角色字段做页面级权限如果时间充足也可以引 Spring Security。毕设题目的核心价值不是“用了多少新技术”而是“是否跑通一个完整业务闭环”。进度管理这类系统里表设计用户、角色、项目、任务、进度记录、操作日志比炫技重要。数据库设计合理、状态流转清晰外审老师就会给高分。6.2 什么时候继续用 SSM什么时候必须上 Boot先说结论新项目尤其前后端分离和微服务项目无脑选 Spring Boot。不是因为它比 SSM 高级而是它能够让你把精力放在业务上而不是天天和 jar 版本过不去。Spring Boot 对测试、监控、容器化也天然友好这也是微服务流行的原因之一。但老项目继续用 SSM 很常见。我接触过一些维护了五六年的业务系统里面积累了大量定制 XML 和特殊配置短时间内改造到 Boot 要冒很大风险。这种时候把 SSM 配置读明白、稳住比“带病迁移”更重要。你可以在老系统旁边新写一个 Boot 服务通过接口对接慢慢替换而不是一把梭重写。如果是多模块工程或者 Gradle 项目Spring Boot 同样支持。Gradle 相比 Maven 构建更快、脚本更灵活但团队如果没有 Gradle 经验强行切换会拉低交付效率。项目选型永远不只看技术还要看团队现状。把 Spring Boot 和模块化结合可以用spring-boot-maven-plugin配合多模块把公共代码抽成内部 lib但模块越多发布和依赖管理就越复杂适合业务确实足够大的情况。说到底SSM 和 Spring Boot 的关系更像地基与预制件的关系。地基里的钢筋水泥还是 Spring 那一套预制件则是 Boot 为你切好的模块。你既要有“从地基看问题”的能力也要有“用预制件快速盖楼”的效率。最后再分享一个我自己的带人习惯新同学入职第一周我会让他用纯 SSM 手写一个用户登录第二周再用 Spring Boot 重写一遍。两次一对比很多“Boot 为什么自动就配置好了”的问题自己就有了答案。这不是让 Boot 走回头路而是用最原始的方式看清工业化的真正价值。