从0到1：我的开源项目成长记
上周五晚上十一点，我瘫在出租屋那张吱呀作响的宜家椅子上，盯着屏幕上 npm publish 成功的提示，长舒一口气。窗外是上海静安区某条小巷子的霓虹灯影，屋里只有机械键盘的回响和泡面桶里最后一口汤的余温。房贷账单刚还完，工资卡余额还没捂热，就又投进了一台新的 Mac Studio —— 没办法，前端动画跑起来太吃性能了，公司那台三年前的 MacBook Pro 已经连 Chrome DevTools 都卡成幻灯片。
我是谁？一个北漂（哦不对，现在算沪漂了）程序员，Vim 党，讨厌鼠标点来点去，日常用 :wq 比用“保存”按钮还顺手。白天在一家中型互联网公司写 Vue + TypeScript，晚上琢磨怎么让 CSS 动画丝滑得像德芙巧克力。最近半年，我搞了个开源项目，叫 MotionEase —— 一个轻量级、声明式的前端交互动画库。今天就想聊聊，这个从“灵光一闪”到“被 GitHub Star 破千”的过程，到底经历了什么。
起因：被产品经理“逼”出来的轮子
事情得从去年双11说起。我们组接了个大活：重构整个电商首页，重点是“沉浸式体验”——说白了就是一堆花里胡哨的滚动视差、元素飞入、悬停涟漪效果。产品经理拿着 Figma 原型，眼神发亮：“我们要让用户一进来就‘哇’一下！”
我翻着原型，心里直打鼓。现有的方案无非是 GSAP、Framer Motion，或者自己撸 requestAnimationFrame。但 GSAP 商业授权贵得离谱（公司法务一听报价直接摇头），Framer Motion 又太重，还强绑 React。我们用的是 Vue 3，团队里还有几个刚转前端的后端同事，让他们手写贝塞尔曲线缓动函数？怕不是要提桶跑路。
更糟的是 deadline：12 月 15 日上线，中间还要过双十二。测试同学已经放话：“要是再出现上次那种‘页面滚到一半突然所有动画卡死’的线上事故，我就在周报里@你三次。”
那天晚上加班到凌晨两点，我盯着控制台里满屏的 Warning: [Violation] 'setTimeout' handler took 120ms，终于忍不住拍桌：“老子自己造个轮子吧！”
开干：从 Vim 里敲出第一行代码
我给自己定了三个原则：
- 轻量：压缩后 ≤ 5KB（gzip）
- 声明式 API：像写 CSS 一样简单
- 框架无关：Vue/React/Svelte 甚至原生 JS 都能用
第一天，我在家附近的咖啡馆窝了一整天，Vim 打开新文件夹，写下 src/core.ts。没用任何脚手架，就靠 tsc + rollup 手搓构建。为什么不用 Vite？因为我想控制每一字节的输出。房贷压力大的人，对“体积”格外敏感。
初期设计时，我翻烂了《CSS Secrets》和《Animation in Web Design》这两本书。特别是 Lea Verou 那本，里面关于 will-change 和 transform 合成层的讲解，直接救了我一命。后来才知道，很多性能问题其实源于浏览器渲染机制的理解偏差，而不是代码本身。
比如，最初我用 left/top 做位移动画，结果 FPS 掉到 20。查了半天才发现，应该用 transform: translateX() —— 这玩意儿能触发 GPU 加速，不占用主线程。这种细节，文档不会写，Stack Overflow 上也得翻几十页才能找到真·答案。
踩坑：那些让我想砸电脑的夜晚
开源哪有那么容易？你以为写完核心逻辑就完了？Too young.
坑一：构建配置地狱
Rollup 的插件生态看似美好，实则深坑无数。我用了 @rollup/plugin-typescript，结果生成的 d.ts 文件路径全错；加了 rollup-plugin-dts 又和 sourcemap 冲突。连续三天，CI 流水线红得像情人节的玫瑰。
最崩溃的是 UMD 构建——为了兼容老项目，得支持 <script> 标签直接引入。结果在 IE11（是的，我们还有 IE 用户！）下报错 Object.assign is not a function。我差点跪下来求运维把 IE 流量切掉。
坑二：测试覆盖率焦虑
一开始我懒，只写了几个手动 demo。直到有人提 issue 说 “Vue 3 Composition API 下动画不触发”，我才意识到：没有自动化测试的开源项目，等于裸奔。
于是硬着头皮学 Vitest + Playwright。写测试用例比写功能还累，尤其是测动画——你怎么断言“这个元素是否真的动了”？最后用了 getComputedStyle(el).transform 来判断矩阵值变化，才勉强覆盖核心路径。
坑三：文档没人看，但你必须写
我自认为 API 设计得很直观：
motion(target, {
from: { opacity: 0, y: 50 },
to: { opacity: 1, y: 0 },
duration: 600,
easing: 'ease-out'
})
结果第一个 PR 就是用户问：“easing 支持 cubic-bezier 吗？” —— 其实文档里写了，但他没看。
从此我明白：文档不是写给聪明人看的，是写给着急的人看的。我重写了 README，加了 GIF 示意图（用 LICEcap 录的，别笑）、常见问题、迁移指南，甚至对比了和其他库的差异。
| 特性 | MotionEase | GSAP | Framer Motion |
|---|---|---|---|
| 体积 (gzip) | 4.2KB | 45KB+ | 28KB+ |
| 框架依赖 | 无 | 无 | React |
| 声明式 API | ✅ | ❌ | ✅ |
| 商业免费 | ✅ | ❌ | ✅ |
这张表成了 README 的流量密码，很多人就是冲着“轻量+免费”来的。
运营：开源不是扔代码，是“养孩子”
以前我以为，代码 push 到 GitHub 就完事了。现实狠狠打了脸。
项目发布第一周，0 star，0 issue。我一度怀疑是不是名字起得太土（MotionEase = Motion + Ease，结果被朋友吐槽像洗衣液）。
后来学乖了：
- 在 Twitter 和 Reddit 的 r/webdev 发帖，标题写“Tiny animation library that doesn’t suck”
- 给 VueUse 提了个 PR，建议集成我们的 hook，被 maintainer 采纳了
- 在知乎写了一篇《为什么我不再用 GSAP》，意外爆了，带来 300+ GitHub 访问
最神奇的是，有个韩国开发者 fork 后，加了韩语文档，还主动帮我翻译了错误提示。那一刻，我真的觉得——开源是有温度的。
当然，也遇到过糟心事。有人提了个 issue，内容就一行：“doesn’t work”，连环境信息都不给。我回复请提供复现步骤，他直接回：“你这库垃圾，我换别的了。” 我默默关掉 issue，喝了口冰美式压压惊。
成果：不只是 Star 数
现在，MotionEase 已经有 1.2k+ stars，被用在至少三个知名开源项目里（包括一个 Vue UI 库）。更重要的是，它真的解决了我们公司的双11需求——上线那天，监控面板里动画相关的卡顿报警为零。测试同学破天荒地在群里发了个“👍”。
技术上，我也收获颇丰：
- 深入理解了浏览器渲染管线（Composite、Paint、Layout）
- 学会了用 Performance Tab 分析帧率
- 甚至顺手优化了公司项目的首屏加载（把动画初始化延迟到
requestIdleCallback）
但最大的成长，其实是心态。
以前我总觉得“写业务代码没技术含量”，总想搞点“高大上”的东西证明自己。现在明白了：真正的工程能力，是在约束条件下做出优雅解。房贷、deadline、IE 用户……这些都不是借口，而是塑造你设计的土壤。
给想做开源的朋友几点建议
- 从小处着手：别一上来就想做“下一代 React”。解决一个具体痛点，比宏大叙事有用得多。
- 文档即产品：你的 README 是门面，示例代码要能一键运行。
- 别怕“重复造轮子”：如果现有轮子又重又贵还不符合你的场景，造一个更好的，就是价值。
- 运营是必修课：发推、写文、参与社区，都是项目的一部分。代码只是 50%。
- 保护自己的时间：我每周只花 5 小时维护项目（周末上午），其余时间陪对象/健身/看《三体》。开源不该 burnout。
对了，最近在读《The Pragmatic Programmer》新版，里面一句话特别戳我：“You’re building your reputation with every line of code you ship.” 开源项目，就是你的技术名片。
写完这篇稿子，已经是凌晨一点。窗外雨声淅沥，泡面桶早扔了，改喝枸杞茶养生。房贷还在，但心里踏实多了——至少，我留下了一点属于自己的代码印记。
如果你也在某个深夜，被需求折磨得想删库跑路，不妨试试：把痛苦变成工具，把抱怨变成 PR。说不定哪天，你的小轮子，也能载着别人驶过泥泞。
最后，MotionEase 的 GitHub 地址就不贴了（怕显得打广告），搜名字就能找到。欢迎 Star，更欢迎 Issue —— 但求你，写清楚复现步骤好吗？🙏
（完）
评论 0