这套组合拳我打了不下几十个项目了——IntelliJ IDEA 负责后端（Java/Spring Boot 那一摊），HBuilderX 负责前端（uni-app 这一摊），两边各自启动、各自打包，最后在服务器或者手机上拼成一个完整产品。听起来是两个工具各干各的，实际上从环境准备到依赖拉取、从调试基座到出包签名，中间踩的坑非常密集。这篇文章我按真实的项目节奏走一遍：先把两边的环境理顺，再分别讲 IDEA 怎么启动后端、HBuilderX 怎么启动前端和真机调试，然后是打包环节（jar、war、Docker 镜像、App 云打包、H5 静态包），最后把联调发布和常见报错整理成速查表。适合刚接手 uni-app + Spring Boot 全栈项目的人，也适合已经会写代码但每次打包都要折腾半天的老手。
1. 工具链和环境先把地基打平
1.1 IDEA 版本选择与 JDK、Maven 的绑定关系
IDEA 目前分两个流派：Ultimate 和 Community（社区版）。做纯 Java/Spring Boot 后端，社区版其实够用，代码补全、Maven 面板、断点调试这些核心功能一个不少；但如果你要跑 Spring Boot 的 Actuator 可视化面板、连数据库的 Database 工具窗口、或者前端框架的深度支持，Ultimate 会顺手很多。我的建议是先用社区版把项目跑起来，确认团队没用到 Ultimate 独占功能再考虑升级，别一上来就折腾授权的事。
真正让人翻车的不是 IDEA 版本，而是JDK 和 Maven 的指向关系。经常出现的一种情况是：IDEA 里编译报No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK，人明明装了 JDK。原因八成是JAVA_HOME指到了 JRE 目录，而 IDEA 的 Maven Runner 默认继承系统环境变量。检查顺序是这样的：
echo $JAVA_HOME # Linux / macOS echo %JAVA_HOME% # Windows CMD java -version # 确认版本与 JAVA_HOME 一致指向的路径必须是 JDK 根目录（含bin/javac），不能是jre子目录。然后在 IDEA 里三处对齐：
File → Project Structure → Project SDK选 JDK 17（或项目要求版本）File → Project Structure → SDKs里确认没混入 JRESettings → Build Tools → Maven → Runner → JRE选同一个 JDK
三处不一致是打包失败的头号原因，尤其是项目里用了maven-compiler-plugin显式指定source/target的时候，SDK 版本低于 target 版本会直接编译报错。
1.2 Maven 私服与依赖拉取的现实问题
公司项目基本都有私服（Nexus 或云效之类的制品库）。新机器上第一次Reload Project，如果settings.xml里没配 mirror 和 server 凭据，会出现一堆Could not resolve dependencies。这时候不要急着删.m2/repository重来，先看报错里的坐标：
- 报错里带
https://repo.maven.apache.org，说明镜没生效，检查Settings → Build Tools → Maven → User settings file是不是指向了你想用的那份 - 报错是 401/403，说明私服账号密码没配到
~/.m2/settings.xml的<servers>里 - 报错是
Could not find artifact xxx:jar:1.0-SNAPSHOT，多半是兄弟模块还没装进本地仓库，先在根目录mvn clean install -DskipTests跑一遍
这里有个经验：多模块项目第一次导入，永远先在命令行跑一次 install，再回 IDEA 里操作。命令行能暴露 IDEA 图形界面里被折叠掉的真实错误，省得你在 Build 窗口里翻半天日志。
1.3 HBuilderX 安装、调试基座和辅助工具
HBuilderX 是绿色版压缩包，解压即用，不需要安装向导。目录别放在中文路径或者带空格的路径下，真机调试和云打包的某些环节对路径很敏感，这是踩过坑之后的习惯。
调试基座（标准基座）是 HBuilderX 自带的、用于真机运行的运行时外壳。你写uni-app的代码，点“运行到手机”，HBuilderX 会把编译产物打到这个基座里跑起来，方便你快速看效果。但标准基座只包含官方内置模块，一旦你在manifest.json里勾选了原生插件（比如地图、推流、原生支付），标准基座就不认了，必须打自定义基座。自定义基座的流程是：发行 → 制作自定义调试基座，走一遍云打包，产出一个专属的 apk/ipa，之后再切到“运行到手机 → 自定义基座”。
顺带说一句依赖服务。后端项目通常要连 MySQL、Redis、RabbitMQ 这些中间件，本地一个个装容易把机器搞乱。我习惯在项目根目录放一份docker-compose.yml，一条命令起全套：
version: "3.8" services: mysql: image: mysql:8.0 ports: ["3306:3306"] environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: demo redis: image: redis:7-alpine ports: ["6379:6379"] rabbitmq: image: rabbitmq:3-management ports: ["5672:5672", "15672:15672"]2. IDEA 端：后端项目启动的完整路径
2.1 导入项目后的第一轮操作
拿到源码，第一种做法是File → Open直接打开项目根目录，IDEA 识别到pom.xml会问你是当 Maven 项目还是普通项目，选 Maven。导入完成后，右侧 Maven 面板会出现模块树，点一下顶部的刷新按钮触发依赖下载。这一步我通常同时做三件事：
一是检查Project Structure → Modules，确认每个模块的Language level和Sources根目录标记正确。有些项目从 Eclipse 迁移过来，src/main/java没有被标成 Sources Root，代码全是红的，看着像依赖问题其实是目录标记问题。
二是在Settings → Editor → File Encodings里把三处编码统一成 UTF-8，包括Global Encoding、Project Encoding和Properties Files。中文字符串在打包后变乱码，九成是这里没统一。
三是看一眼application.yml或者application-dev.properties里的数据库、Redis 地址，跟你本地 compose 起的端口对不对得上。对不上就直接改本地配置，不要改提交到仓库的那份，后面第 5 章讲配置分离时会细说。
2.2 三种启动方式，按场景选
第一种，主类启动。找到@SpringBootApplication标注的启动类，左边绿色三角点下去。这是日常开发用得最多的方式，改完代码按Ctrl+F9重新编译，再点重启，几秒钟的事。Run 面板里能直接看日志、看端口监听信息、看 Bean 加载耗时。
第二种，外置 Tomcat 启动。只有当项目是传统 war 包、必须部署到外部容器里时才用。配置方式是Run → Edit Configurations → + → Tomcat Server → Local，指定 Tomcat 安装目录，然后在Deployment标签页里加 Artifact。这里有个细节：Artifact 要选xxx:war exploded而不是xxx:war，前者是解压目录，支持热更新，后者每次都要重新打一遍。
第三种，Docker 里启动。有些团队把后端也容器化，本地用docker compose up起整个后端服务。这种方式的代价是调试不方便，改一行代码要重新构建镜像。折中方案是把中间件放 Docker 里，后端应用仍然在 IDEA 里跑，这是我个人最推荐的组合。
三种方式对比一下：
| 启动方式 | 适用场景 | 热更新 | 调试体验 | 启动耗时 |
|---|---|---|---|---|
| 主类启动 | 日常开发 | 支持（配合 DevTools） | 最好 | 3~10 秒 |
| 外置 Tomcat | 传统 war 项目 | 改 JSP 支持 | 一般 | 15 秒以上 |
| Docker 容器 | 环境一致性验证 | 不支持 | 较差 | 30 秒以上 |
2.3 端口冲突和配置覆盖
启动报Web server failed to start. Port 8080 was already in use的时候，先别急着改配置，先查是谁占了：
# macOS / Linux lsof -i :8080 kill -9 <PID> # Windows netstat -ano | findstr :8080 taskkill /PID <PID> /F找到进程之后要判断一下，很多情况下占端口的正是你自己上一次没关干净的调试实例。IDEA 默认允许同一个配置开多个实例，连续点两次启动就会撞端口。可以在Edit Configurations → Modify options → Allow multiple instances里确认这个开关的状态。
如果确实需要换端口，优先用启动参数覆盖而不是改配置文件：
-Dserver.port=8081写进VM options里，本地随便折腾，也不会污染仓库里的配置。这个习惯配合后面的配置分离，能让你的本地环境和 CI 环境彻底解耦。
2.4 启动慢、内存飙高的调优思路
Spring Boot 项目启动慢，先看日志里的 Bean 初始化耗时，通常集中在数据源连接、Redis 连接池初始化、以及各种@PostConstruct里干重活的地方。有个直接的判断方法：把日志级别调到DEBUG，看哪个包下的初始化花的时间最长。
内存方面，IDEA 自身和 JVM 是两笔开销。JVM 侧在VM options里加：
-Xms512m -Xmx1024m -XX:+UseG1GCIDEA 自身的内存改Help → Change Memory Settings，默认值偏保守，调到 2048m 以上会明显顺畅。但注意别把机器内存吃满，否则编译和容器一起抢内存，反而更慢。我一般留出至少 4G 给 Docker 和浏览器。
另外有个不影响功能但影响心情的点：关掉不用的插件。IDEA 自带的插件几十个，实际用不到一半。Settings → Plugins里把和当前技术栈无关的关掉，索引速度和启动速度都会好一截。
3. HBuilderX 端：前端项目怎么启动才顺
3.1 uni-app 项目导入与运行目标的区别
HBuilderX 打开项目也是文件 → 打开目录，选到manifest.json所在的目录。打开之后，运行菜单下会列出当前项目支持的所有目标平台：运行到浏览器、运行到小程序模拟器、运行到手机或模拟器、运行到内置浏览器。
这几个目标对应的编译产物完全不同，理解这一点能省下大量排查时间：
- 运行到浏览器：产出 H5 版本，走 HTTP 服务，最容易调试，但拿不到原生能力
- 运行到微信开发者工具：产出小程序格式的代码，HBuilderX 会调用微信开发者工具打开
- 运行到手机或模拟器：产出 App 运行时代码，打进调试基座里
小程序这条链路我解释得细一点，因为它卡人的地方最多。要让 HBuilderX 把代码送进微信开发者工具，需要先在微信开发者工具里打开设置 → 安全设置 → 服务端口，把它打开。这一步不做的话，HBuilderX 控制台会一直提示找不到开发者工具。然后在 HBuilderX 的工具 → 设置 → 运行配置里，找到“微信开发者工具路径”，填到cli.bat（Windows）或对应可执行文件的位置。两个路径都配对之后，点“运行到小程序模拟器”，微信开发者工具会自动拉起并加载项目。
3.2 修改 HBuilderX 内置服务的端口
“启动修改端口”这个需求太常见了，因为 8080、5173 这些默认端口经常被后端占着。分两种情况：
情况一，H5 开发服务器端口。在manifest.json里，切到“源码视图”，找到h5节点：
"h5": { "devServer": { "port": 8090, "disableHostCheck": true }, "router": { "mode": "hash", "base": "./" } }改完port保存，重新运行到浏览器就生效了。注意router.base设成./是为了后面打包部署到子目录时静态资源路径不出错，这个放到第 4 章细说。
情况二，HBuilderX 自身的预览服务端口。有些版本 HBuilderX 会自己起一个本地服务用于内置浏览器预览，端口冲突时可以在工具 → 设置 → 运行配置里找到相关项调整。不同的 HBuilderX 版本设置项位置略有差异，找不到就在设置面板里搜“端口”关键词。
改完端口记得把后端的跨域白名单同步一下，否则前端起来了、请求全被拦，会误以为是业务代码的问题。
3.3 前端代理解决跨域，别去动后端
开发阶段前后端不同源，浏览器一定拦跨域。最省事的做法是在前端配置代理，让开发服务器替你把请求转发到后端。
如果用 Vue3 + Vite 的模板，在vite.config.js里配：
export default defineConfig({ server: { port: 8090, proxy: { '/api': { target: 'http://127.0.0.1:8081', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } })如果用 Vue2 模板，配置在vue.config.js的devServer.proxy里。两种写法的关键参数都是changeOrigin: true，它会把请求头里的 Host 改成目标地址，否则后端拿到的 Host 还是前端的端口，某些做了 Host 校验的框架会直接拒绝。
注意：
127.0.0.1和localhost在有些环境里解析结果不同（一个走 IPv4 一个可能走 IPv6），代理目标统一写127.0.0.1能少一类玄学问题。
真机调试时更麻烦一点，因为手机的localhost指手机自己。这时候代理目标要写成电脑在局域网里的 IP，比如http://192.168.1.10:8081，并且确保防火墙放行、手机和电脑在同一个网段。这一步不通的话，App 里所有接口都超时，看着像后端挂了。
4. 打包：两边各自产出什么，怎么出
4.1 IDEA 打 jar 包，从命令到产物
Spring Boot 项目的标准出包命令就一条：
mvn clean package -DskipTests但这条命令背后有几个容易忽略的点。第一，package只把当前模块打成包，多模块项目里如果依赖了兄弟模块，兄弟模块必须已经在本地仓库里，否则会报找不到。所以完整的出包顺序是：
mvn clean install -DskipTests -pl common,dao,service -am mvn package -DskipTests -pl web-pl指定模块，-am表示同时构建依赖的模块。这个写法在 CI 上很常见，能省掉大量无用构建时间。
第二，产物要真的能java -jar起来，靠的是spring-boot-maven-plugin的 repackage 目标。如果 pom 里漏了这段配置，打出来的 jar 只有几十 KB，是个“瘦包”，一运行就报no main manifest attribute：
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <executions> <execution> <goals><goal>repackage</goal></goals> </execution> </executions> <configuration> <mainClass>com.demo.Application</mainClass> </configuration> </plugin> </plugins> </build>mainClass在只有一个启动类时可以省略，但多模块项目里最好显式写，避免插件猜错。
第三，-DskipTests只是跳过测试执行，测试代码仍然会编译。如果测试代码本身有编译错误，照样打包失败。真要完全跳过编译测试代码，用-Dmaven.test.skip=true，两个参数的区别值得记一下。
4.2 打 war 包部署到外部容器
项目如果是packaging为war，改动比 jar 多两步。一是把内置 Tomcat 从运行时排除（部署到外部容器时不需要）：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency>二是启动类要继承SpringBootServletInitializer并重写configure方法，否则外部 Tomcat 根本找不到你的应用入口。
产出的 war 直接丢进 Tomcat 的webapps目录，访问路径会带上 war 包名。想让它跑在根路径，就把 war 重命名为ROOT.war，这是老项目里最常见的做法。另外注意，外部 Tomcat 的版本要和新版 Spring Boot 要求的 Servlet 规范对得上，版本不匹配会报类找不到，排查时先确认这一条。
4.3 打包成 Docker 镜像的两种写法
镜像构建我试过两条路。第一条是纯 CLI，项目根目录写Dockerfile：
FROM eclipse-temurin:17-jre WORKDIR /app COPY target/app.jar app.jar ENV TZ=Asia/Shanghai EXPOSE 8081 ENTRYPOINT ["java","-jar","/app/app.jar"]然后docker build -t demo-backend:1.0.0 .，再docker run -d -p 8081:8081 demo-backend:1.0.0。这种方式透明、可控，缺点是每次都要手动 copy jar。
第二条是用 Maven 插件在打包阶段顺手构建镜像，比如 jib 或者docker-maven-plugin。好处是mvn package一条命令同时产出 jar 和镜像，适合放进 CI。代价是本地必须跑着 Docker daemon，而且镜像分层策略如果不调优，每次构建都是全量，推送到镜像仓库会很慢。
实操心得：Dockerfile 里基础镜像尽量选
-jre而不是-jdk，体积能小一半；时区用ENV TZ设置，比改基础镜像省事。容器里跑 Java 还要注意 JVM 会读取容器内存上限，JDK 10 以后默认开启容器感知，之前的老版本需要加-XX:+UseContainerSupport。
还有一个坑是.dockerignore。如果不排除target、node_modules、.git，构建上下文会非常大，docker build第一步就要卡很久。加上.dockerignore之后构建速度会有肉眼可见的提升。
4.4 HBuilderX 打包 App：云打包与离线打包
App 打包先理解一个前提：HBuilderX 本身不产出原生安装包，它产出的是运行时代码，最终要靠云打包服务或者 Android Studio/Xcode 离线工程把代码塞进原生壳里。
云打包是最省事的路径。流程是：manifest.json里配置好应用名称、appid、版本号、图标、启动图，然后发行 → 原生App-云打包，选择 Android/iOS，填证书，勾选需要的原生模块，提交。Android 需要 keystore 文件、证书别名、证书密码；iOS 需要 .p12 证书和 .mobileprovision 描述文件。
# 生成 Android 签名证书（JDK 自带工具） keytool -genkey -v -keystore demo.keystore -alias demo \ -keyalg RSA -keysize 2048 -validity 36500这个命令有几个参数要留意：-validity 36500大概是 100 年，商店上架的 App 都用这种长有效期，免得证书过期后无法更新；-alias和密码一定要记牢，丢了就只能换包名重发，用户数据全丢。目标 SDK 版本按各应用市场的最新要求设置，设置过低在上架审核时会被打回。
离线打包适合有原生插件定制、或者不方便走云端的团队。做法是用 HBuilderX 的发行 → 原生App-本地打包 → 生成本地打包App资源，拿到dist/resources目录，再下载官方 Android 离线 SDK，用 Android Studio 打开，把资源目录替换进去，配置dcloud_control.xml里的 appid，然后正常编译出 apk。这条路灵活度高，但每次 HBuilderX 升级 SDK 都要跟着更新工程，维护成本不低。
自定义调试基座和正式包的关系也要理清楚：基座只是调试用的壳，最终上架必须走正式云打包或离线打包。两者的appid必须一致，否则会出现基座里能跑、正式包里接口报签名错误的诡异问题。
4.5 H5 打包和部署到 Nginx
H5 打包走发行 → 网站-PC Web 或手机H5，产物在dist/build/h5。这个目录扔到 Nginx 的静态目录里就能访问，但要注意三件事：
第一，资源路径。如果站点部署在子路径（比如https://demo.com/app/），必须把manifest.json里h5.router.base设成./或者/app/，否则打包出来的 HTML 引用的是/static/js/xxx.js，浏览器会去根路径找，直接 404。
第二，路由模式。history 模式下，用户在/user/123这个地址刷新页面，Nginx 会去找这个物理路径，同样是 404。两个解法：一是把路由模式改成 hash；二是在 Nginx 里加 try_files 回退：
location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }第三，接口地址。开发时用的代理在打包后完全失效，生产环境要么把接口地址写成完整域名，要么在 Nginx 里配一层/api反向代理到后端。我倾向于后者，前端代码里只写相对路径，环境切换时改 Nginx 配置就行，不用重新打包前端。
5. 联调和发布：把两端的产出接起来
5.1 配置分离，别让本地配置进仓库
Spring Boot 的配置按 profile 拆：application.yml放公共项，application-dev.yml、application-test.yml、application-prod.yml放各自的差异项。启动时用--spring.profiles.active=dev指定。
打包的时候，环境相关的配置不要硬编码进 jar。两种做法各有取舍：一种是把配置外置到 jar 同级目录，jar 启动时会优先读外部的application-prod.yml；另一种是用环境变量覆盖，比如SPRING_DATASOURCE_URL。容器化部署时，环境变量这种方式更自然，配合 K8s 的 ConfigMap 用起来很顺。
前端这边，uni-app可以在manifest.json里配置不同平台的差异化参数，但接口地址这类东西，我更习惯用一个config.js集中管理，打包时用条件编译区分：
// #ifdef H5 export const BASE_URL = '/api' // #endif // #ifdef APP-PLUS export const BASE_URL = 'https://api.demo.com' // #endif这样同一份代码在不同平台产出正确的地址，不用每次手动改。
5.2 版本号和包名管理
App 的版本号管理有个硬性规则要记住：manifest.json里的version.name是给用户看的（1.0.0 这种），version.code是给系统判断升级用的，必须是递增的整数。应用市场上传新包时，如果version.code没有比线上版本大，会直接被拒。
包名（Android 的package、iOS 的bundleId）一旦定下来就不要再改，改了等于新应用，老用户收不到更新。建议一开始就用反向域名格式，比如com.company.projectname，别用默认的io.dcloud.xxx，默认包名是没办法上架的。
后端 jar 包的版本号同理，pom.xml里的version配合 CI 的流水线自动递增，别手动改，容易和镜像 tag 对不上。我见过因为镜像 tag 写成latest导致回滚时拉错版本的事故，后来团队统一改成“版本号 + 提交短哈希”的 tag 规则，出问题一眼能定位。
5.3 上线前的自检清单
发布前我会固定走一遍这些检查，顺序不换：
- 后端 jar 本地
java -jar能起，接口能通 - 前端包在本地起一个静态服务器能跑，接口地址指向正确
- 打包时引用的证书和密钥文件确实在，没有引用到个人电脑上的绝对路径
- 数据库脚本已经执行，新加字段有默认值或允许为空
- App 的权限声明和实际使用的原生模块对得上，多声明会被审核问，少声明会运行时崩溃
这几条看着基础，但每次发版总有一条会被漏掉，尤其是第三条——CI 上跑得好好的，是因为密钥配在流水线的环境变量里，本地手动打包时忘了带。
6. 启动和打包常见问题速查
6.1 启动阶段的典型报错
| 报错信息 | 大概率原因 | 处理动作 |
|---|---|---|
| Port 8080 was already in use | 端口被占用 | 查进程并结束，或改用-Dserver.port |
| No compiler is provided in this environment | JAVA_HOME 指向 JRE | 改指 JDK 根目录，三处 SDK 对齐 |
| Could not resolve dependencies | 私服配置或凭据问题 | 检查 settings.xml 的 mirror 和 servers |
| 找不到微信开发者工具 | 服务端口未开或路径没配 | 微信工具开服务端口，HBuilderX 配路径 |
| 真机请求全部超时 | 代理目标写成了 localhost | 改成电脑局域网 IP，放行防火墙 |
| Bean 创建失败 | 配置文件项缺失或类型不符 | 看完整堆栈，定位到具体属性名 |
这类问题有个通用的排查思路：从上往下看第一处 ERROR，不要从最后一行看。Spring 的异常链很长，最后一行的Caused by有时候只是表象，真正的根因在中间某一行。
6.2 打包阶段的坑
Maven 打包报错里，出现频率最高的三类：编译错误、依赖缺失、插件配置问题。编译错误最直接，日志里会带文件名行号。依赖缺失按第 1.2 节的顺序查。插件配置问题最隐蔽，典型表现是打包成功但产物跑不起来。
我整理过一份自检顺序：
- 产物大小是否合理？几十 KB 的 Spring Boot jar 一定有问题
META-INF/MANIFEST.MF里的Main-Class和Start-Class是否正确- 依赖的第三方 jar 是否全在
BOOT-INF/lib下 - 打包用的 JDK 版本是否和运行环境的 JDK 一致
第四条特别容易忽略。用 JDK 21 编译、服务器上装的是 JDK 17，启动时会报UnsupportedClassVersionError，而且报错信息里那个版本号（比如 65.0）很多人对不上号。记住 17 对应 61、21 对应 65 就好查了。
6.3 真机调试和 App 打包的排错
真机连不上，先排除物理层：数据线换一根、USB 调试开关打开、驱动装好。Android 部分机型还需要在开发者选项里打开“USB 安装”，否则 HBuilderX 识别到设备但装不上基座。
基座装上去闪退，常见原因是基座版本和 HBuilderX 版本不匹配。判断方法很直接：HBuilderX 控制台会提示当前基座版本，版本号对不上就重新制作一次。另一个原因是manifest.json里勾了原生模块但用的是标准基座，这种报错通常提示“当前基座不支持 xxx 模块”，解决办法就是打自定义基座。
云打包排队时间长的时候，别反复提交，同一时间多个任务排队反而更慢。真正的提速手段是提前把该填的填好：证书、图标、启动图、权限说明、隐私政策配置。隐私政策这项现在各市场都强制要求，manifest.json里没配的话，打包能成功但上架会被拒。
关于签名，还有个实际操作中的细节：keystore 文件建议用 Base64 编码后存进流水线的密钥管理里，本地不要留明文。团队成员离职、电脑重装这类事情发生时，你就知道这个习惯有多重要了。
我个人在实际操作中的体会是，IDEA 和 HBuilderX 这套组合最容易出问题的环节从来不是写代码，而是“环境配置的隐式依赖”——IDEA 依赖的 JDK 版本、Maven 的 settings 位置、HBuilderX 依赖的基座版本、签名文件路径，这些在项目文档里往往写不全，全靠接手的人自己摸索。我现在接手新项目的第一个动作，就是在 README 里补一份“从零到跑通”的操作记录，把自己踩过的每一步都写进去。花半小时写的东西，能让下一个人少花一天，这笔账怎么算都划算。
