1. 从“ponytail”这个标题说起它到底是什么第一次看到“ponytail”这个词很多人脑子里蹦出来的画面是扎在脑后的那束马尾辫。但在技术圈和工具链语境里它早就不是发型那么简单了。我最早接触这个词是在一个前端工程化的讨论群里有人甩了一句“你们还在手动拼配置ponytail 一把梭就完事了”当时我还以为是某个新出的打包器。后来自己上手折腾了一圈才明白ponytail 本质上是一套围绕“轻量、可插拔、低侵入”思路构建的工具集合它既可以指代一个具体的插件体系也可以泛指那种“把复杂流程收束成一条主线”的工程哲学。热搜里频繁出现的“ponytail skill”“ponytail 插件”“插件 ponytail 如何使用”其实指向的是同一个核心诉求大家想知道这东西能干什么、怎么装、怎么用、踩不踩坑。我写这篇东西的目的很直接就是把我自己从零开始摸 ponytail 的整个过程摊开来讲包括我为什么选它、中间卡在哪儿、最后怎么跑通的。不管你是刚听说这个词的新手还是已经装了一半没跑起来的老哥都能从里面找到能直接抄的步骤和能避开的坑。需要先说明一点ponytail 并不是某个单一厂商垄断的产品它更像一个约定俗成的能力集合不同团队、不同项目里落地形态会有差异。所以下面我讲的具体操作是基于我实际用过的那套方案来展开的你在自己环境里可能需要做少量适配但核心逻辑是通的。2. 为什么我会选择 ponytail 这套方案2.1 传统做法的三个痛点在正式聊 ponytail 之前得先说说我为什么放弃原来的做法。我之前的项目里处理类似需求用的是“大而全”的方案一个主配置文件管所有事所有功能模块都往里塞。刚开始还行等到模块数量超过十个配置文件膨胀到八百多行改一个参数要在里面翻半天而且改完还不敢确定有没有影响到别的模块。这是第一个痛点配置耦合太深。第二个痛点是启动慢。每次跑任务不管用不用得上所有模块都得初始化一遍冷启动时间从最初的两秒涨到后来的十几秒。第三个痛点是扩展难。想加一个新功能得先读懂原有配置的结构再找到合适的插入点稍不注意就破坏了原有逻辑。这三个问题叠加在一起让我开始寻找更轻的替代方案ponytail 就是在这个背景下进入视野的。2.2 ponytail 的核心设计思路ponytail 的思路可以用一句话概括把一条完整的流程拆成若干条独立的“发束”每束只负责一件事用的时候才扎起来。这个比喻很贴切马尾辫本身就是把散开的头发收束成一股ponytail 做的是反过来的事——它先把能力拆散再按需收束。具体来说它有三个设计特征。第一是按需加载每个功能模块独立注册不调用就不初始化冷启动时间能压到原来的三分之一左右。第二是配置分离每个模块带自己的配置片段主配置只负责引用改一个模块不会波及全局。第三是接口统一不管内部多复杂对外暴露的调用方式是一致的学一次就能套用到所有模块上。这三点加起来正好对应了我前面说的三个痛点。2.3 和其他方案对比它赢在哪我拿它和另外两种常见做法做过对比。一种是纯手写脚本灵活是灵活但每个项目都要重写一遍复用性差。另一种是重型框架功能全但学习曲线陡小项目用起来像杀鸡用牛刀。ponytail 卡在中间比手写脚本多了标准化接口和模块管理比重型框架轻得多核心包体积控制在几十KB级别。对比维度纯手写脚本重型框架ponytail 方案冷启动速度快慢较快配置复杂度低但重复高中等且可拆分模块复用性差好好学习成本低高中等适合项目规模极小大型中小型到大型这个表格是我自己实测后整理的不是官方数据。你可以看到 ponytail 在几个关键维度上都没有明显短板这也是我最终选它的原因。3. ponytail 插件的安装与基础配置3.1 环境准备与依赖检查装 ponytail 插件之前先把环境理清楚。我用的运行环境版本是 18.x 以上低于这个版本部分 API 会报错。你可以用下面这行命令确认当前版本node -v如果版本不够先去升级。另外确认包管理器用的是 npm 还是 yarn两者在依赖解析上偶有差异我建议统一用 npm避免混用导致的锁文件冲突。检查一下全局有没有旧版本残留npm list -g --depth0看到列表里有 ponytail 相关的旧包先卸干净再装新的不然容易出现“装了但没生效”的诡异情况。这个坑我踩过一次排查了半小时才发现是旧版本在作祟。3.2 安装步骤与目录结构说明安装本身不复杂一行命令的事npm install ponytail-core --save-dev装完之后项目根目录下会多出一个ponytail.config.js文件这是主入口配置。同时node_modules里会出现ponytail-core目录里面按模块分了子目录。我建议你装完后先别急着改配置跑一遍自带的初始化命令npx ponytail init这个命令会生成一套默认的目录结构大致长这样ponytail/主目录modules/存放各个功能模块configs/存放模块级配置片段logs/运行日志cache/缓存文件这个结构的好处是职责清晰模块和配置分开管理找东西的时候不用满项目翻。我见过有人把所有东西塞在一个目录里后期维护起来非常痛苦所以这一步别偷懒。3.3 核心配置项逐个拆解打开ponytail.config.js默认内容不长但每一项都有讲究。我挑几个关键的说。第一个是entry指定主入口模块默认是modules/index.js。如果你想把入口放在别处改这里就行但要注意路径写法相对路径和绝对路径都支持我习惯用相对路径迁移项目时不用改。第二个是autoLoad布尔值控制是否自动加载所有模块。默认是false也就是按需加载。如果你项目小、模块少可以设成true省去手动注册的麻烦。但模块一多建议保持false不然启动速度会受影响。第三个是logLevel日志级别可选debug、info、warn、error。开发阶段用debug能看到详细的加载过程上线后改成warn减少日志量。我一般开发时开debug方便定位问题。第四个是cacheDir缓存目录路径。ponytail 会把模块的编译结果缓存到这里二次启动时直接读缓存速度能快不少。默认是./ponytail/cache你可以改到磁盘空间大的分区。提示改完配置后记得重启一次部分配置项不支持热更新改了不重启不生效。4. ponytail skill 的实操流程与关键环节4.1 创建一个自定义 skill 模块ponytail skill 说白了就是一个符合规范的功能模块。创建过程分三步。第一步在modules/目录下新建一个文件夹名字就是你的 skill 名比如my-skill。第二步在里面建一个index.js这是模块入口。第三步写模块定义最小结构长这样module.exports { name: my-skill, version: 1.0.0, init(context) { // 初始化逻辑 }, run(input) { // 核心执行逻辑 return result; } };name是模块唯一标识不能和已有模块重名。init在模块加载时调用一次适合做初始化。run是每次调用时执行的核心逻辑。这个结构看着简单但每个字段都有用别省略。4.2 skill 的注册与调用方式写完模块后要在主配置里注册。打开ponytail.config.js找到modules数组把新模块加进去modules: [ ./modules/my-skill ]注册完在代码里这样调用const ponytail require(ponytail-core); const result await ponytail.run(my-skill, inputData);注意run是异步的返回 Promise记得用await或.then处理。我第一次用的时候忘了加await拿到的结果是undefined排查了半天才发现是异步没处理。这个坑很典型新手容易犯。4.3 参数传递与返回值处理skill 之间传参有个约定输入统一走input对象输出统一走return。不要用全局变量传值那样模块之间会产生隐式依赖后期很难维护。我见过一个项目模块 A 往全局对象上挂数据模块 B 去读结果模块 B 单独跑的时候拿不到数据直接崩了。返回值建议用对象包裹比如{ success: true, data: result }这样调用方能统一判断成功与否。如果直接返回裸数据调用方没法区分“正常返回空值”和“执行失败”容易误判。注意skill 的run方法里不要写死循环或长时间阻塞的操作ponytail 默认有超时机制超时会中断执行并记录日志。如果你的任务确实耗时长把超时时间调大或者拆成多个小任务分批执行。5. 实操过程中踩过的坑与排查技巧5.1 模块加载失败的常见原因模块加载失败是我遇到最多的问题表现是启动时报module not found或者模块注册了但调用时报undefined。原因通常有三个。一是路径写错相对路径的基准目录是项目根目录不是配置文件所在目录这点容易搞混。二是模块名重复两个模块用了同一个name后注册的会覆盖先注册的。三是模块文件有语法错误加载时直接抛异常。排查方法很简单先把logLevel设成debug重启后看日志里模块加载的详细过程哪一步断了日志里都有记录。如果日志里没线索单独写个测试脚本直接require那个模块文件看能不能正常加载这样能快速定位是模块本身的问题还是注册环节的问题。5.2 配置不生效的排查思路配置改了不生效先确认三件事。第一改的是不是当前环境用的配置文件有些项目有多套配置开发环境和生产环境分开改错了文件自然不生效。第二改完有没有重启前面说过部分配置不支持热更新。第三配置项名称有没有拼错ponytail 对配置项名称是大小写敏感的autoLoad写成autoload就不认。如果这三条都排除了还不生效去看缓存目录。ponytail 会把配置的解析结果缓存起来缓存没清掉的话读的还是旧配置。手动删掉cache/目录下的文件再重启基本能解决。5.3 性能问题的定位方法ponytail 用久了偶尔会遇到启动变慢或者执行卡顿。定位性能问题我一般分两步走。第一步看日志里的时间戳找出哪个模块加载耗时最长。第二步针对那个模块单独做性能分析看是初始化逻辑太重还是run方法里有慢操作。我遇到过一次启动慢日志显示某个模块加载花了三秒多。进去一看那个模块在init里做了一次网络请求去拉远程配置网络慢的时候就把整个启动拖住了。后来改成异步加载启动时先跳过用到的时候再拉问题就解决了。这个经验告诉我init里尽量只做轻量操作重活放到run里按需执行。问题现象可能原因排查方法解决方式模块加载失败路径错误/重名/语法错误开 debug 日志单独 require 测试修正路径、改名、修语法配置不生效改错文件/未重启/拼写错误核对文件名、重启、检查拼写改对文件、重启、修正拼写启动变慢init 里有重操作看日志时间戳定位模块重操作移到 run 或异步化调用返回 undefined异步未处理检查是否加 await补上 await 或 then这张表是我自己整理的速查表遇到问题先对号入座能省不少排查时间。6. ponytail 的扩展玩法与进阶建议6.1 多 skill 组合编排单个 skill 能力有限真正好用的时候是把多个 skill 串起来。ponytail 支持在配置里定义执行链比如先跑fetch-data再把结果传给process-data最后交给save-data。配置写法是在modules里加一个pipeline字段pipeline: [ { skill: fetch-data, input: {} }, { skill: process-data, input: ${prev} }, { skill: save-data, input: ${prev} } ]${prev}是占位符表示上一个 skill 的输出。这样编排的好处是逻辑清晰每一步的输入输出都能追溯。我建议编排的链路不要超过五步太长了调试起来麻烦中间某一步出错要一层层往回找。6.2 自定义配置片段的复用前面说过每个模块可以带自己的配置片段放在configs/目录下。这些片段可以跨项目复用比如你写了一个通用的日志配置片段新项目直接拷过去就能用。我习惯把常用配置片段整理成一个模板库新项目初始化时按需引入省去重复配置的时间。复用的时候注意版本对齐不同版本的 ponytail 对配置片段的格式要求可能有细微差异。引入前先看下目标项目的 ponytail 版本版本差太多的话配置片段可能需要微调。6.3 什么时候该考虑换方案ponytail 不是万能的。如果你的项目模块数量超过五十个或者对启动速度有极致要求比如毫秒级那 ponytail 的按需加载机制可能还是不够快这时候要考虑更底层的方案。另外如果团队里没人熟悉这套东西维护成本会比较高选型时要把学习成本算进去。我的判断标准是项目规模中等、模块数量在十个到三十个之间、团队有基本的前端工程化经验ponytail 是合适的选择。超出这个范围要么往轻了走用纯脚本要么往重了走用成熟框架别硬套。7. 关于 ponytail 使用的一些个人体会折腾 ponytail 这段时间最大的感受是“轻量”和“规范”这两件事其实不矛盾。以前总觉得要规范就得牺牲轻量要轻量就得忍受混乱ponytail 用模块化和统一接口把这两者捏到了一起。当然它也不是没有代价前期搭结构、写模块定义会多花一些时间但这些投入在后期维护时会成倍还回来。我现在的习惯是新项目只要模块数量超过五个就直接上 ponytail先把骨架搭好再填内容。搭骨架那半小时比后期重构省下的时间多得多。另外一个小技巧把常用的 skill 模块整理成一个私有包新项目直接装连复制粘贴都省了。这个做法我用了一年多实测下来很稳推荐你也试试。
1. 从“ponytail”这个标题说起它到底是什么第一次看到“ponytail”这个词很多人脑子里蹦出来的画面是扎在脑后的那束马尾辫。但在技术圈和工具链语境里它早就不是发型那么简单了。我最早接触这个词是在一个前端工程化的讨论群里有人甩了一句“你们还在手动拼配置ponytail 一把梭就完事了”当时我还以为是某个新出的打包器。后来自己上手折腾了一圈才明白ponytail 本质上是一套围绕“轻量、可插拔、低侵入”思路构建的工具集合它既可以指代一个具体的插件体系也可以泛指那种“把复杂流程收束成一条主线”的工程哲学。热搜里频繁出现的“ponytail skill”“ponytail 插件”“插件 ponytail 如何使用”其实指向的是同一个核心诉求大家想知道这东西能干什么、怎么装、怎么用、踩不踩坑。我写这篇东西的目的很直接就是把我自己从零开始摸 ponytail 的整个过程摊开来讲包括我为什么选它、中间卡在哪儿、最后怎么跑通的。不管你是刚听说这个词的新手还是已经装了一半没跑起来的老哥都能从里面找到能直接抄的步骤和能避开的坑。需要先说明一点ponytail 并不是某个单一厂商垄断的产品它更像一个约定俗成的能力集合不同团队、不同项目里落地形态会有差异。所以下面我讲的具体操作是基于我实际用过的那套方案来展开的你在自己环境里可能需要做少量适配但核心逻辑是通的。2. 为什么我会选择 ponytail 这套方案2.1 传统做法的三个痛点在正式聊 ponytail 之前得先说说我为什么放弃原来的做法。我之前的项目里处理类似需求用的是“大而全”的方案一个主配置文件管所有事所有功能模块都往里塞。刚开始还行等到模块数量超过十个配置文件膨胀到八百多行改一个参数要在里面翻半天而且改完还不敢确定有没有影响到别的模块。这是第一个痛点配置耦合太深。第二个痛点是启动慢。每次跑任务不管用不用得上所有模块都得初始化一遍冷启动时间从最初的两秒涨到后来的十几秒。第三个痛点是扩展难。想加一个新功能得先读懂原有配置的结构再找到合适的插入点稍不注意就破坏了原有逻辑。这三个问题叠加在一起让我开始寻找更轻的替代方案ponytail 就是在这个背景下进入视野的。2.2 ponytail 的核心设计思路ponytail 的思路可以用一句话概括把一条完整的流程拆成若干条独立的“发束”每束只负责一件事用的时候才扎起来。这个比喻很贴切马尾辫本身就是把散开的头发收束成一股ponytail 做的是反过来的事——它先把能力拆散再按需收束。具体来说它有三个设计特征。第一是按需加载每个功能模块独立注册不调用就不初始化冷启动时间能压到原来的三分之一左右。第二是配置分离每个模块带自己的配置片段主配置只负责引用改一个模块不会波及全局。第三是接口统一不管内部多复杂对外暴露的调用方式是一致的学一次就能套用到所有模块上。这三点加起来正好对应了我前面说的三个痛点。2.3 和其他方案对比它赢在哪我拿它和另外两种常见做法做过对比。一种是纯手写脚本灵活是灵活但每个项目都要重写一遍复用性差。另一种是重型框架功能全但学习曲线陡小项目用起来像杀鸡用牛刀。ponytail 卡在中间比手写脚本多了标准化接口和模块管理比重型框架轻得多核心包体积控制在几十KB级别。对比维度纯手写脚本重型框架ponytail 方案冷启动速度快慢较快配置复杂度低但重复高中等且可拆分模块复用性差好好学习成本低高中等适合项目规模极小大型中小型到大型这个表格是我自己实测后整理的不是官方数据。你可以看到 ponytail 在几个关键维度上都没有明显短板这也是我最终选它的原因。3. ponytail 插件的安装与基础配置3.1 环境准备与依赖检查装 ponytail 插件之前先把环境理清楚。我用的运行环境版本是 18.x 以上低于这个版本部分 API 会报错。你可以用下面这行命令确认当前版本node -v如果版本不够先去升级。另外确认包管理器用的是 npm 还是 yarn两者在依赖解析上偶有差异我建议统一用 npm避免混用导致的锁文件冲突。检查一下全局有没有旧版本残留npm list -g --depth0看到列表里有 ponytail 相关的旧包先卸干净再装新的不然容易出现“装了但没生效”的诡异情况。这个坑我踩过一次排查了半小时才发现是旧版本在作祟。3.2 安装步骤与目录结构说明安装本身不复杂一行命令的事npm install ponytail-core --save-dev装完之后项目根目录下会多出一个ponytail.config.js文件这是主入口配置。同时node_modules里会出现ponytail-core目录里面按模块分了子目录。我建议你装完后先别急着改配置跑一遍自带的初始化命令npx ponytail init这个命令会生成一套默认的目录结构大致长这样ponytail/主目录modules/存放各个功能模块configs/存放模块级配置片段logs/运行日志cache/缓存文件这个结构的好处是职责清晰模块和配置分开管理找东西的时候不用满项目翻。我见过有人把所有东西塞在一个目录里后期维护起来非常痛苦所以这一步别偷懒。3.3 核心配置项逐个拆解打开ponytail.config.js默认内容不长但每一项都有讲究。我挑几个关键的说。第一个是entry指定主入口模块默认是modules/index.js。如果你想把入口放在别处改这里就行但要注意路径写法相对路径和绝对路径都支持我习惯用相对路径迁移项目时不用改。第二个是autoLoad布尔值控制是否自动加载所有模块。默认是false也就是按需加载。如果你项目小、模块少可以设成true省去手动注册的麻烦。但模块一多建议保持false不然启动速度会受影响。第三个是logLevel日志级别可选debug、info、warn、error。开发阶段用debug能看到详细的加载过程上线后改成warn减少日志量。我一般开发时开debug方便定位问题。第四个是cacheDir缓存目录路径。ponytail 会把模块的编译结果缓存到这里二次启动时直接读缓存速度能快不少。默认是./ponytail/cache你可以改到磁盘空间大的分区。提示改完配置后记得重启一次部分配置项不支持热更新改了不重启不生效。4. ponytail skill 的实操流程与关键环节4.1 创建一个自定义 skill 模块ponytail skill 说白了就是一个符合规范的功能模块。创建过程分三步。第一步在modules/目录下新建一个文件夹名字就是你的 skill 名比如my-skill。第二步在里面建一个index.js这是模块入口。第三步写模块定义最小结构长这样module.exports { name: my-skill, version: 1.0.0, init(context) { // 初始化逻辑 }, run(input) { // 核心执行逻辑 return result; } };name是模块唯一标识不能和已有模块重名。init在模块加载时调用一次适合做初始化。run是每次调用时执行的核心逻辑。这个结构看着简单但每个字段都有用别省略。4.2 skill 的注册与调用方式写完模块后要在主配置里注册。打开ponytail.config.js找到modules数组把新模块加进去modules: [ ./modules/my-skill ]注册完在代码里这样调用const ponytail require(ponytail-core); const result await ponytail.run(my-skill, inputData);注意run是异步的返回 Promise记得用await或.then处理。我第一次用的时候忘了加await拿到的结果是undefined排查了半天才发现是异步没处理。这个坑很典型新手容易犯。4.3 参数传递与返回值处理skill 之间传参有个约定输入统一走input对象输出统一走return。不要用全局变量传值那样模块之间会产生隐式依赖后期很难维护。我见过一个项目模块 A 往全局对象上挂数据模块 B 去读结果模块 B 单独跑的时候拿不到数据直接崩了。返回值建议用对象包裹比如{ success: true, data: result }这样调用方能统一判断成功与否。如果直接返回裸数据调用方没法区分“正常返回空值”和“执行失败”容易误判。注意skill 的run方法里不要写死循环或长时间阻塞的操作ponytail 默认有超时机制超时会中断执行并记录日志。如果你的任务确实耗时长把超时时间调大或者拆成多个小任务分批执行。5. 实操过程中踩过的坑与排查技巧5.1 模块加载失败的常见原因模块加载失败是我遇到最多的问题表现是启动时报module not found或者模块注册了但调用时报undefined。原因通常有三个。一是路径写错相对路径的基准目录是项目根目录不是配置文件所在目录这点容易搞混。二是模块名重复两个模块用了同一个name后注册的会覆盖先注册的。三是模块文件有语法错误加载时直接抛异常。排查方法很简单先把logLevel设成debug重启后看日志里模块加载的详细过程哪一步断了日志里都有记录。如果日志里没线索单独写个测试脚本直接require那个模块文件看能不能正常加载这样能快速定位是模块本身的问题还是注册环节的问题。5.2 配置不生效的排查思路配置改了不生效先确认三件事。第一改的是不是当前环境用的配置文件有些项目有多套配置开发环境和生产环境分开改错了文件自然不生效。第二改完有没有重启前面说过部分配置不支持热更新。第三配置项名称有没有拼错ponytail 对配置项名称是大小写敏感的autoLoad写成autoload就不认。如果这三条都排除了还不生效去看缓存目录。ponytail 会把配置的解析结果缓存起来缓存没清掉的话读的还是旧配置。手动删掉cache/目录下的文件再重启基本能解决。5.3 性能问题的定位方法ponytail 用久了偶尔会遇到启动变慢或者执行卡顿。定位性能问题我一般分两步走。第一步看日志里的时间戳找出哪个模块加载耗时最长。第二步针对那个模块单独做性能分析看是初始化逻辑太重还是run方法里有慢操作。我遇到过一次启动慢日志显示某个模块加载花了三秒多。进去一看那个模块在init里做了一次网络请求去拉远程配置网络慢的时候就把整个启动拖住了。后来改成异步加载启动时先跳过用到的时候再拉问题就解决了。这个经验告诉我init里尽量只做轻量操作重活放到run里按需执行。问题现象可能原因排查方法解决方式模块加载失败路径错误/重名/语法错误开 debug 日志单独 require 测试修正路径、改名、修语法配置不生效改错文件/未重启/拼写错误核对文件名、重启、检查拼写改对文件、重启、修正拼写启动变慢init 里有重操作看日志时间戳定位模块重操作移到 run 或异步化调用返回 undefined异步未处理检查是否加 await补上 await 或 then这张表是我自己整理的速查表遇到问题先对号入座能省不少排查时间。6. ponytail 的扩展玩法与进阶建议6.1 多 skill 组合编排单个 skill 能力有限真正好用的时候是把多个 skill 串起来。ponytail 支持在配置里定义执行链比如先跑fetch-data再把结果传给process-data最后交给save-data。配置写法是在modules里加一个pipeline字段pipeline: [ { skill: fetch-data, input: {} }, { skill: process-data, input: ${prev} }, { skill: save-data, input: ${prev} } ]${prev}是占位符表示上一个 skill 的输出。这样编排的好处是逻辑清晰每一步的输入输出都能追溯。我建议编排的链路不要超过五步太长了调试起来麻烦中间某一步出错要一层层往回找。6.2 自定义配置片段的复用前面说过每个模块可以带自己的配置片段放在configs/目录下。这些片段可以跨项目复用比如你写了一个通用的日志配置片段新项目直接拷过去就能用。我习惯把常用配置片段整理成一个模板库新项目初始化时按需引入省去重复配置的时间。复用的时候注意版本对齐不同版本的 ponytail 对配置片段的格式要求可能有细微差异。引入前先看下目标项目的 ponytail 版本版本差太多的话配置片段可能需要微调。6.3 什么时候该考虑换方案ponytail 不是万能的。如果你的项目模块数量超过五十个或者对启动速度有极致要求比如毫秒级那 ponytail 的按需加载机制可能还是不够快这时候要考虑更底层的方案。另外如果团队里没人熟悉这套东西维护成本会比较高选型时要把学习成本算进去。我的判断标准是项目规模中等、模块数量在十个到三十个之间、团队有基本的前端工程化经验ponytail 是合适的选择。超出这个范围要么往轻了走用纯脚本要么往重了走用成熟框架别硬套。7. 关于 ponytail 使用的一些个人体会折腾 ponytail 这段时间最大的感受是“轻量”和“规范”这两件事其实不矛盾。以前总觉得要规范就得牺牲轻量要轻量就得忍受混乱ponytail 用模块化和统一接口把这两者捏到了一起。当然它也不是没有代价前期搭结构、写模块定义会多花一些时间但这些投入在后期维护时会成倍还回来。我现在的习惯是新项目只要模块数量超过五个就直接上 ponytail先把骨架搭好再填内容。搭骨架那半小时比后期重构省下的时间多得多。另外一个小技巧把常用的 skill 模块整理成一个私有包新项目直接装连复制粘贴都省了。这个做法我用了一年多实测下来很稳推荐你也试试。
