企业官网建设流程全解析

新建一个前端项目，最耗神的往往不是第一行业务代码，而是打开目录后那半小时：删示例组件、改package.json里的名字、把端口从默认值拧开、补上.gitignore、把 README 里的标题换成自己的项目。一套下来，手是热的，脑子是凉的。init-skeleton这个工具解决的正是这件事——它是 Brunch 生态里的骨架初始化器，负责把一个现成的“骨架仓库”（skeleton repo）克隆下来、清掉版本历史、改写项目名，再顺手把依赖装好，交给你一个能直接npm start的空壳应用。这篇文章不讲概念吹捧，只讲它每一步在干什么、参数怎么选、骨架仓库该怎么写才能被它正确消费，以及我在实际使用中撞过的那些坑。不管你是第一次听说 Brunch，还是已经用它跑了几个项目，下面的内容都能直接抄去用。

1. 先把“骨架”这件事想明白：它到底替你省了什么

1.1 骨架仓库不是文件模板，而是“可运行的起点”

很多人对骨架的理解停留在“一堆文件夹的压缩包”，这个认知会让你把骨架做废。真正的骨架仓库，验收标准只有一条：把它克隆下来、装完依赖、执行启动命令，浏览器能出页面，控制台无报错。它必须是一个已经跑通的工程，而不是一个待填空的脚手架。

这两者的差别很实在。压缩包式的模板只需要目录结构对，文件内容对不对没人管；而可运行的骨架，意味着brunch-config.js里的入口配置、app/下的示例组件、vendor/里的第三方脚本，全都要能协同工作。只有这样，初始化出来的新项目才有资格叫“起点”——新手拿到它，先把业务代码写进去就行，不用先去修构建配置。

我见过一些团队把骨架做成“半成品”，比如故意留一个空的app/index.html，美其名曰“让开发者自己决定”。结果每个新项目第一天都在重复同样的动作：抄一份 HTML、补一段<script>、调一遍端口。骨架的价值恰恰在于消灭这种重复，所以它必须完整、必须能跑。

1.2 init-skeleton 在工具链里的位置

Brunch 的初始化链路其实很短，init-skeleton是其中最底层的那个执行者。你在命令行敲的brunch new <骨架> <目标目录>，本质上就是把参数透传给init-skeleton，由它去完成“拉取、清理、改写、安装”这套动作。也就是说，学会直接调init-skeleton，你既可以用brunch new的便利，也可以在 CI 脚本、内部工具里单独调用它。

这个分层设计有个好处：骨架来源和构建工具解耦。骨架可以放在任何支持克隆的远程仓库里，也可以是本地的一个目录，甚至可以是别人维护的公共骨架。init-skeleton只关心“怎么把一个仓库变成一个干净的项目目录”，不关心这个仓库是谁写的、里面用的是 Sass 还是 Less。这种单一职责让它在脚本里非常听话——参数给对，行为就确定。

顺带说一句，它的能力边界也很清楚：它不负责帮你生成业务模块、不负责跑代码检查、不负责改构建配置。想在这些环节偷懒，得另外写脚本，别指望它。

1.3 什么样的项目适合用骨架起步

不是所有项目都值得做骨架。我的判断标准是：同一套技术选型会被复用三次以上，就值得沉淀。比如一个团队长期做后台管理界面，技术栈固定为 Brunch + 某个前端框架 + 一套内部组件库，那骨架就是刚需；反过来，只做一次的活动页、试验性质的小 Demo，直接建目录反而更快。

骨架的另一个隐藏收益是“约束”。新项目从同一个起点长出来，目录结构、命名习惯、构建入口天然一致，接手别人项目时的认知成本会低很多。这一点在多人协作里比省下的那点时间值钱得多——你不会再遇到“这个项目的样式为什么放在styles/而不是app/styles/”这类问题。

但也要接受代价：骨架是活的，技术栈升级、依赖打补丁，都得回头维护它。如果你没有精力维护，那它很快就会从“最佳实践”退化成“祖传配置”。所以更稳妥的做法是，先做一个最小可用版本（能跑、目录干净、配置够用），跑满三个真实项目之后再考虑加插件、加代码生成。一上来就做大而全的骨架，基本都会死在第二次升级上。

2. 一次初始化到底发生了什么：五个阶段拆开看

2.1 阶段一：把源地址解析成可拉取的目标

init-skeleton的第一步是把你在命令行里写的那个字符串，翻译成 Git 能理解的目标。它有几种常见写法，弄清楚这几种，能少走很多弯路。

第一种是平台简写，形如<用户名>/<仓库名>，工具会自动补全成完整的远程地址。这是最省事的写法，也是日常用得最多的。第二种是完整远程地址，https://...或git@...开头都行，适合自建托管或者需要走特定协议的场景。第三种是带分支或标签的简写，用#分隔，比如<用户名>/<仓库名>#v2，这个后面会专门讲，是版本锁定的关键。第四种是本地路径，指向你磁盘上某个目录，适合骨架还在开发调试阶段——改完不用推远程，直接拿本地目录试初始化效果。

解析这一步出错的表现通常很直接：命令刚跑就报“找不到仓库”或“无法解析地址”。多数情况是简写拼错了用户名，或者仓库是私有的、当前环境没有访问凭据。先手动用git clone同样的地址试一次，能不能拉下来立刻见分晓。

2.2 阶段二：克隆到临时位置，而不是直接铺到目标目录

这个设计细节值得单独说。常见实现是把骨架先克隆到系统临时目录下的一个随机位置，处理完再搬到你的目标目录。为什么不直接克隆到目标目录？因为目标目录可能已经存在、可能非空、甚至可能就是当前目录.。先克隆到临时位置，等于给自己留了一个可回退的缓冲区：处理过程中任何一步失败，你的目标目录都还是干净的。

临时目录这个设计也解释了另一个常见现象：初始化完成后，目标目录里没有.git，但临时目录可能残留。如果某次初始化异常中断，去系统临时目录看看，通常会有一两个以brunch或随机串命名的残留文件夹，删掉即可，不影响后续操作。

还有一个容易被忽略的点：克隆通常是浅克隆。只取目标分支最近一次提交，不带完整历史。这对初始化来说完全够用，还快；但对“想基于骨架的历史做 diff”这种需求就不行了，那种场景得自己手动 clone。理解这一点，你就不会疑惑为什么初始化出来的项目只有一个提交都不到的历史——它根本就没打算给你历史。

2.3 阶段三：清历史、清残留

克隆完紧接着就是清理，核心动作是删掉.git目录。这一步的意义不只是“去掉别人的提交记录”，更重要的是切断与原骨架仓库的关联。如果不删，新项目会带着骨架仓库的远程地址，开发者一不小心就把业务代码推到骨架仓库去了，这事故不小。

除了.git，还有几类东西需要清理或留意。一是骨架自带的构建产物目录（比如public/下的编译结果），这些东西是骨架作者本地环境生成的，对新项目毫无意义，还会让人误以为“已经构建过了”。二是骨架自己的锁文件，这里有个细节后面第 6 章会展开——package-lock.json里记着骨架的项目名，改名之后如果不重建，依赖树会显示不一致。三是 CI 配置、编辑器配置里跟骨架作者个人习惯绑定的部分，比如某些人喜欢提交.vscode/settings.json，这种就别往骨架里塞。

清理环节最容易出问题的是隐藏文件。如果你自己写脚本处理骨架（而不是用现成工具），用普通的目录遍历很容易漏掉以点开头的文件，导致.gitignore、.editorconfig这类关键文件丢失。这类 bug 特别隐蔽，因为项目照样能跑，只是团队协作时才发现该忽略的东西没被忽略。

2.4 阶段四：改写名称与占位符

这是整个流程里唯一带“智能”的部分，也最容易出问题。最基础的动作是把骨架package.json里的name字段改成目标目录名。听起来简单，但它带来的连锁反应不少：锁文件里的名字对不上了、README 里的项目名还是老的、页面标题可能写死了骨架名。

比基础改写更进一步的，是占位符机制。有些骨架会在需要替换的地方留一个固定标记，初始化时统一替换成目标名。不同版本的实现支持的占位符语法不完全一致，稳妥的做法是：别指望工具替你干所有替换，把需要替换的地方收敛到少数几个文件（package.json、README.md、页面标题所在的模板文件），然后写一个十几行的脚本兜底。这个脚本后面我会给一份现成的。

这里有个判断原则：凡是“人一眼能看出是骨架名”的地方，都应该被替换；凡是“技术标识符”的地方（比如某个 CSS 类名前缀），可以保留，因为改动成本高于收益。把边界划清楚，比追求全自动更重要。

2.5 阶段五：装依赖与收尾

最后一步是安装依赖。默认行为是直接执行安装，让新项目出生即可用。这一步失败率其实不低，原因通常集中在这几处：网络环境导致包拉不下来、某个依赖的版本在新环境下有兼容问题、骨架的postinstall脚本里写了只有骨架作者本地才成立的逻辑。

我的建议是分两次做：第一次初始化时加--no-install，先看看目录结构和文件内容对不对，确认无误再手动装依赖。这样出问题时，你能明确区分是“骨架本身有问题”还是“依赖安装失败”，排查半径小很多。直接一次性装完再报错，你面对的是一团纠缠的因果关系。

装完之后值得花两分钟做一次冒烟验证：启动开发服务器、打开页面、看控制台有没有红色报错、随便改一行样式确认热更新生效。这四步过了，才算真正初始化完成。

3. 命令怎么拼：参数选择与常见组合

3.1 目标路径的三种写法与 --force 的边界

目标路径的写法有三种常见形态，各有适用场景。第一种是相对目录名，如my-app，会相对于当前工作目录创建。这是最常用的，也最安全。第二种是.（当前目录），适合你已经mkdir好并cd进去的情况，常见于“先用工具建好目录再初始化”的流程。第三种是绝对路径，多见于脚本里，好处是不依赖执行位置。

.这种写法有个坑：当前目录只要有任何文件（哪怕是一个.DS_Store），就可能被判定为非空而拒绝执行。这时候--force就登场了。它的作用是“我确认知道这个目录不是空的，仍然继续”。用之前一定要想清楚：目标目录里的东西会被覆盖吗？会不会把已有的代码冲掉？

我的原则是--force只在一个场景下用：目录里只有我明确知道可以丢弃的临时文件。其余情况，宁可换个目录名重来。初始化是一次性动作，重来成本极低；覆盖造成的数据丢失，成本极高。这个账不用算就知道怎么选。

3.2 --no-install 的两种必须场景

--no-install是我用得最多的参数，没有之一。两种场景下它几乎是必须的。

第一种是排查骨架问题。你怀疑骨架本身有问题，想看看到底是文件结构不对还是依赖装不上，那就先不装依赖，打开目录逐个文件过一遍。没有node_modules的目录更干净，找问题也更快。

第二种是依赖需要特殊处理。比如你的环境需要走特定的包源、需要加装某些本地依赖、或者需要先改package.json里的某个版本号再装。这时候让工具自动装完反而添乱——它会先按骨架写的版本装一遍，你再改再装一遍，浪费时间还可能留下脏的锁文件。

还有一种半必须的场景：批量初始化。要在脚本里一次建十个项目，装依赖的时间会成倍放大，先把目录铺好、再统一装，可控性更好。具体做法后面第 5 章会给示例。

3.3 用 # 锁定分支与标签

骨架会演进，这就有个问题：今天初始化出来的项目，和下个月初始化出来的，配置可能不一样。如果你希望某类项目永远从固定的版本起步，就要用#锁定。

#后面可以跟分支名，也可以跟标签名。跟分支名的效果是“跟随这条分支的最新提交”，适合骨架还在活跃迭代的阶段；跟标签名的效果是“永远取这个快照”，适合骨架已经稳定、只做安全更新的阶段。我的习惯是：骨架仓库维护一条长期分支给新项目用，打标签标记每次“已验证”的状态，初始化时优先用标签。这样出问题能快速定位到“哪次骨架变更引入的”。

需要注意，锁定标签的代价是错过修复。如果骨架后来修了一个安全漏洞，用旧标签的项目不会自动获得。所以标签策略要配合第 7 章的变更通知机制一起用，不能只锁不管。

提示：不同版本的参数名可能有细微差异，动手前先跑一次帮助命令确认，比照抄博客配置可靠得多。

4. 做一个能被正确消费的骨架仓库

4.1 目录骨架与必须存在的文件

一个合格的 Brunch 骨架，目录不需要花哨，但必须完整。最小集合大概是这些：app/放源码（app/assets/、app/components/、app/index.html）、vendor/放不需要经过包管理器的第三方脚本、package.json声明依赖和脚本、brunch-config.js声明构建规则、.gitignore忽略node_modules和编译输出。

app/index.html是入口，Brunch 会把它作为页面模板处理，编译后的结果落到输出目录。app/components/里放至少一个示例组件，它承担两个作用：证明构建链路是通的、给新项目一个写代码的位置参考。别小看这个示例，它的写法会被后来所有项目模仿，所以要写得规范。

vendor/这个目录现在用得少了，因为 Brunch 支持直接从node_modules里引入依赖。但如果你们团队有内部维护的、不发布到包仓库的脚本，放这里最方便。注意vendor/下的文件默认会被单独打成一个包，跟业务代码分开，这个隔离是好事，加载顺序也更可控。

4.2 brunch-config.js 里哪些值必须从环境读、哪些可以写死

配置文件是骨架的灵魂，写得好不好直接决定新项目顺不顺手。一份精简但够用的配置长这样：

// brunch-config.js module.exports = { files: { javascripts: { joinTo: { 'js/app.js': /^app/, 'js/vendor.js': /^(?!app)/ } }, stylesheets: { joinTo: 'css/app.css' } }, paths: { watched: ['app', 'vendor'] }, modules: { wrapper: 'commonjs', definition: false, autoRequire: { 'js/app.js': ['initialize'] } }, npm: { enabled: true }, server: { port: Number(process.env.PORT) || 3333, hostname: '0.0.0.0' } };

几个关键点值得展开。joinTo用对象形式配合正则，能把app/下的代码和第三方依赖分别打成一个文件，避免业务代码改动导致整个包缓存失效——这是构建性能上的实际收益，不是玄学。autoRequire指定入口模块，应用启动时自动执行，省掉手写初始化调用。

端口必须从环境变量读，这一条请务必写进骨架。团队里两个人同时起服务，写死端口必然撞车；CI 环境里端口也可能被占用。留一个process.env.PORT || 3333的兜底，成本一行，收益巨大。同理，任何跟本机环境相关的值（代理设置、输出目录的特殊路径）都不该写死在骨架里。

反过来，modules.wrapper这类跟代码风格强相关的配置就该写死。骨架的意义是统一，不是提供无限选项，把该定的定下来，新项目才不会五花八门。

4.3 package.json 与占位符约定

package.json是初始化的重点关注对象。骨架里的name字段写什么？建议写一个明确的、一看就知道是骨架的名字，比如web-starter-skeleton。这样初始化后如果没被正确替换，你一眼就能发现——总比写个模糊的名字，事后分不清是用错了骨架还是没改名要好。

scripts里至少要有三条：开发、构建、生产构建。开发用brunch watch --server，构建用brunch build，生产用brunch build --production。这三条覆盖了日常绝大多数场景，新项目不需要再想“启动命令是什么”。

至于更细的占位符替换，我给你一个十几行的兜底脚本，放进骨架的scripts/目录，初始化后手动跑一次：

// scripts/rename.js const fs = require('fs'); const path = require('path'); const newName = process.argv[2]; if (!newName) { console.error('用法: node scripts/rename.js <新项目名>'); process.exit(1); } const targets = ['package.json', 'README.md', 'app/index.html']; const oldName = 'web-starter-skeleton'; targets.forEach((file) => { const abs = path.resolve(__dirname, '..', file); if (!fs.existsSync(abs)) return; const content = fs.readFileSync(abs, 'utf8'); fs.writeFileSync(abs, content.split(oldName).join(newName), 'utf8'); console.log(`已处理 ${file}`); });

这个脚本刻意写得很笨：目标文件写死、只做纯文本替换、不遍历目录。笨有笨的好处——它不会在你没预期的地方改东西。想扩展就手动往targets数组里加一个文件名，可控。

4.4 提交前清理清单

骨架仓库最怕的就是“作者本地的痕迹”混进去。推代码之前，照着下面这份清单过一遍：

• node_modules/绝对不能提交，确认.gitignore已生效。
• 编译产物目录（通常是public/）不要提交，让它由构建生成。
• 编辑器个人配置、系统生成的隐藏文件（如.DS_Store）清掉。
• package-lock.json要么提交、要么不提交，二选一，别一会儿有一会儿没有。
• README 里不要留“本项目是某某的骨架”之外的私人说明。
• 任何测试用的临时接口地址、密钥占位、个人分支名，全部删掉。

这份清单不是形式主义。骨架会被复制到每一个新项目里，一个不该提交的文件，会被复制几十次，清理成本是乘法的。我踩过最典型的一次，是骨架里带了一个本地调试用的环境配置，结果后面每个新项目都带着它，直到有人把它误当成正式配置改了起来。

5. 完整实操：从一个骨架地址到跑起来的应用

5.1 环境准备与版本核对

先确认环境。Node 版本建议用当前的 LTS，太老的版本会在依赖安装阶段遇到各种语法不兼容；包里自带的版本管理工具能省掉切换版本的手动操作。确认 Node 和包管理器都在 PATH 里，node -v和对应的版本查询命令能正常输出版本号。

接下来确认工具本身可用。最简单的办法是用npx直接调用，不需要全局安装，每次拿最新的稳定版：

npx init-skeleton --help

帮助信息能出来，说明环境没问题，顺便也能看到你这台机器上这个版本实际支持哪些参数——这一步很重要，网上搜到的参数可能和你手上的版本对不上。

如果是团队协作，建议把骨架地址和版本固定写进内部文档，而不是让人凭记忆敲。地址写错一个字符，报错信息往往很含糊，排查要花时间。

5.2 执行初始化并逐项验收

先做一次“不装依赖”的初始化，看清骨架长什么样：

npx init-skeleton your-org/web-starter-skeleton#v1 my-app --no-install cd my-app ls -a

ls -a里的-a很关键，确认隐藏文件（.gitignore等）都在，同时确认.git目录不存在。接着检查三个文件：package.json里name是不是变成了my-app、brunch-config.js里的端口是不是从环境变量读的、app/index.html的标题是不是还是骨架名。

都没问题再装依赖：

npm install npm start

启动后打开http://localhost:3333（端口按你配置的来），页面能出来、控制台没红字、改一行样式能热更新，三条过完，初始化算完成。如果有任何一条不过，退回上一步看文件内容，别急着重装依赖——问题多半在骨架本身。

5.3 初始化后的第一轮改造

初始化只给你一个能跑的壳，真正让它变成你的项目，还需要一轮改造，大概四件事。

第一件，跑一次改名脚本，把残留的骨架名清干净：node scripts/rename.js my-app。跑之前先git status看一下，跑完git diff扫一眼改了什么，别盲目相信脚本。

第二件，删掉示例组件里用不到的部分。骨架给的示例通常包含几个演示用的组件和样式，留着它们只会干扰后来人。删的时候注意同步清理引用，别留下悬空的 import。

第三件，初始化版本控制。git init、提交一次“初始化”记录。这个基线提交很有价值，之后所有改动都能跟它对比，出问题能看清是骨架的问题还是业务代码的问题。

第四件，把项目名、端口、接口地址这类环境相关的东西过一遍，该进配置文件的进配置文件，该进环境变量的进环境变量。这一步做完，项目才算真正属于你。

5.4 编进脚本：非交互调用与编程接口

如果你们经常需要一次建多个项目，或者要把初始化塞进内部工具，直接调编程接口更顺手：

// tools/create-app.js const initSkeleton = require('init-skeleton'); const path = require('path'); async function create(name) { const target = path.resolve(process.cwd(), name); await initSkeleton('your-org/web-starter-skeleton#v1', target, { install: false }); console.log(`已创建 ${name}，接下来请执行 npm install`); } create(process.argv[2]).catch((err) => { console.error('初始化失败:', err.message); process.exit(1); });

接口形式在不同版本间可能有差异，第三个参数支持哪些选项，最稳妥的办法是翻一眼你安装版本里的说明文件，或者直接看帮助输出。写脚本时把install关掉，把安装交给后续步骤，这样失败时你能清楚知道问题出在哪一段。

批量场景下，建议串行执行而不是并发。同时克隆多个仓库对网络和磁盘都有压力，而且日志会交织在一起，排查困难。串行慢一点，但过程可读。

6. 踩坑实录与排查表

6.1 克隆阶段：地址对了也拉不下来

最常见的是权限问题。私有仓库需要当前环境有可用的访问凭据，而init-skeleton调用的是底层 Git，凭据配置得在 Git 层面生效，不能指望工具帮你处理登录。判断方法很简单：拿同样的地址手动git clone一次，能拉下来就说明是工具的问题，拉不下来就是凭据的问题。

第二种是网络抖动导致克隆中断。表现是“克隆到一半失败”或“超时”。这种重试往往就好了，但如果反复失败，检查一下是否需要走特定的网络配置——注意这部分属于环境配置范畴，具体做法请遵循你所在环境的规范。

第三种是标签或分支写错。#v1写成了#V1，或者标签根本不存在，报错信息通常只说“找不到引用”，不会明确告诉你标签错了。这时候去远程仓库的标签列表里核对一眼最快。

6.2 安装阶段：依赖装不上或装完跑不起来

依赖安装失败的原因排布很集中。版本不兼容占大头，尤其是骨架做出来之后过了几个月，某些依赖发了不兼容的新版本，而骨架里写的是范围版本号（^开头），一装就装到了新版本。解决办法是把关键依赖的版本锁死，去掉^。

第二种是postinstall脚本作怪。有些依赖装完会自动执行脚本，脚本里假设了某些环境条件，在你的机器上不成立。表现是安装“成功”但启动报错。排查办法是看安装日志里有没有脚本执行失败的提示。

第三种是锁文件冲突。骨架里带的锁文件如果和package.json对不上，安装过程会尝试修复，有时候修出奇怪的结果。我的做法是初始化后直接删掉锁文件重新生成一次，反正新项目的依赖树本来就该是新的。

6.3 改名失灵与文件丢失

改名失灵有两种表现。一种是package.json的name没变，多半是目标目录名的推断出了问题（比如用了.作为目标路径），手动改一下即可。另一种是页面标题、README 里还是骨架名，这是占位符没覆盖到，用第 4 章那个脚本兜底。

文件丢失最隐蔽的是隐藏文件。如果你不用现成工具而是自己写复制逻辑，一定要处理点开头的文件。另外要注意，某些包管理器在打包发布时会把.gitignore改名，如果你的骨架既要走仓库克隆又要发布成包，这条规则会咬你一口——克隆路径不受影响，包路径下文件名会变。

6.4 几条不太容易想到的经验

第一，初始化完先别急着写业务代码。花十分钟把骨架给的示例代码读一遍，你会知道构建配置是怎么组织的、组件是怎么注册的。这份认知在后期改配置时能省下大量时间。

第二，保留一次“原始骨架”的对照。初始化完成后，把初始状态提交一次，之后任何时候怀疑“是不是骨架配置有问题”，都能跟这次提交 diff 一下，快速定位是骨架的问题还是你自己改出来的问题。

第三，别在骨架里放太多个性化配置。曾经有一版骨架里塞了作者自己的编辑器配置和一套很复杂的代码检查规则，结果每个新项目第一天都在处理检查报错，而不是写功能。骨架的原则是“够用就好”，花哨的东西留给具体项目按需加。

7. 把骨架当长期资产维护

7.1 版本与分支策略

骨架一旦被多个项目依赖，就不能随便改了。我的做法是维护一条稳定分支，所有“已验证可用”的状态打上标签，初始化时锁标签。日常开发在另一条分支上进行，验证通过一版，才合并到稳定分支并打新标签。

这样做的收益是可控性。某个项目初始化出来有问题，你能立刻回答“它用的是哪个标签”，然后拿那个标签的骨架复现一次。没有标签，你面对的是一段随时间漂移的历史，排查只能靠猜。

标签命名建议带上语义，比如v1.2.0，并在说明里写清楚这一版改了什么。别用日期当标签，日期看不出内容，三个月后没人记得20240601到底改了什么。

7.2 变更怎么传导到已有项目

这是骨架维护里最容易被忽略的一环。骨架的变更不会自动传导到已经初始化的项目，这是设计使然——每个项目从骨架出来后就是独立的了。所以你需要一套通知机制。

轻量做法是维护一份变更记录，每次骨架更新时写清楚“改了什么、影响哪些项目、要不要手动同步”。重一点的做法，是把骨架里那些通用部分抽成一个可复用的包，让项目通过依赖引用的方式获得更新，而不是靠复制。后者的工程成本高，适合骨架已经稳定、复用面很广的团队。

我的选择是中间路线：构建配置这类“改了就该同步”的内容，写一份对照说明；业务示例代码这类“各项目自己演化”的内容，不同步。划清这条线，维护成本就下来了。

7.3 我的几条硬规矩

最后分享几条踩出来的规矩，都是小事，但省时间。

骨架里所有依赖必须锁版本，不允许^出现在关键依赖上。范围版本号在骨架场景下是风险源，你无法预期半年后初始化出来的项目会装到什么版本。

骨架必须自带一次“冒烟测试”的说明，哪怕只是三行字：怎么启动、打开哪个地址、看到什么算成功。这行字会在每个新项目的第一天被用到。

初始化流程必须能在离线或弱网状态下走完“不装依赖”那半程，这样网络出问题时你至少能拿到目录结构，不至于卡死在第一步。

骨架的 README 第一段必须写清楚适用场景和不适用场景。我见过太多人拿着一个为单页应用准备的骨架去搭后台系统，然后花两天删代码——这不是骨架的问题，是说明没写清楚。

按照这些规矩维护下来的骨架，用起来会很省心：地址一贴、命令一敲、三分钟一个能跑的项目。这个投入产出比，值得每个长期维护同类型项目的团队认真对待一次。