你一定遇到过这种情况：一个简单的日期格式化，你纠结要不要引入 moment.js；一个弹窗组件，你在想是手写还是用 antd。选错了，要么项目臃肿，要么浪费时间重复造轮子。
这个问题，我把它叫做前端开发的"平衡木"------一边是"不写代码就不会犯错"的稳妥，一边是"自己写才能掌控一切"的执念。
但深入这个领域越久，我越发现：我们需要平衡的，远不止"用不用库"这一个维度。真正让人头疼的，是那些每天都在发生、却没有标准答案的"跷跷板"时刻。
为什么我们总是失衡？
前端可能是软件工程里"选择最多"的领域。框架有三四家，构建工具五六种，状态管理七八套，组件库数不过来。每个选择背后，都站着两个互相拉扯的力量。
失衡的根源其实很简单：资源永远是有限的（时间、人力、认知负荷、预算），而我们总想用有限的资源，去覆盖无限的可能性。你永远不可能同时做到"最快交付""最佳性能""最完美代码"和"最前沿技术"。
所以，所谓的"平衡"，就是在有限资源下，找到那个"当下最优解"。它不是"五五开"的静态点，而是一个动态调节的过程------项目初期可以偏向效率（快速验证），中期需要偏向规范（控制熵增），后期则要偏向稳定（谨慎变更）。而最难的，是你得知道"现在是什么阶段"。
六条需要反复踩的"跷跷板"
以下六个支点，每一个踩歪的人都付出了代价，每一次调整也都换来了喘息的空间。
1. 用库还是自研：所有问题的起点
这是一个关于"外部依赖"与"自主可控"的平衡。
左边是"用库"：快速解决问题，但把代码的"生死"交给别人。右边是"自研"：完全掌控，但要付出开发成本和长期的维护代价。
情景 ：你需要在项目中实现一个日期选择器。原生
<input type="date">样式太丑，交互也简陋。你搜到了三个库：一个是老牌的react-datepicker，有 10 年历史、周下载量百万，但 API设计陈旧，依赖 moment.js（体积大）；一个是刚发布一年的
react-aria-datepicker，设计优雅、无样式、完全可定制，但文档只有英文，社区案例少；还有一个是国内团队做的
mtd-datepicker，文档全中文，示例丰富，但最近一次 commit 是半年前，issues 里有人问"什么时候支持 React19"，没人回。
你选哪个？选第一个，项目可能重
200KB；选第二个，团队要花时间读英文文档、自己写样式；选第三个，万一它半年后不维护了，你的代码就和它一起沉没。
思考方向：这不是"用不用库"的问题，而是"用哪个库"和"用库的成本"的问题。引入一个库，等于把你的代码和它的生命周期绑定。你需要问自己：
- 如果它明年不维护了，我有能力 fork 继续修吗？
- 它的 API 设计和我团队的习惯冲突，谁迁就谁？
- 它的体积对首屏加载的影响，能接受吗？
- 它的学习曲线，团队要花多久爬过去？
一条可用的标尺：
- 核心差异化功能（你的项目靠这个赢）→ 自研，值得投入
- 通用辅助功能（没有它也能用）→ 用库，但要尽职调查
- 尽职调查清单：维护状态（commit 频率、issue 响应）、生态文档（案例多吗）、打包大小（支持 Tree Shaking 吗）、API 设计（优雅吗）
- 即使是自研，也要借鉴经典实现------不要从零发明轮子，从零调教轮子
2. 性能优化：极致体验 vs 开发效率
这是一个关于"用户感受"与"开发者感受"的平衡。
左边是"极致体验"：页面秒开，交互丝滑，用户开心。右边是"开发效率"：快速交付，少写代码，开发者开心。
情景：你的后台管理系统首屏加载 3 秒，老板说"太慢了，隔壁竞品 1.5 秒，优化到 1 秒以内"。你打开 Network 面板，发现最大的几个包来自 ECharts（800KB）、Antd（600KB）、Monaco Editor（2MB）。拆还是不拆？
拆的话，你要做：ECharts 按需引入（但项目里用了 20 种图表，按需配置要一周）；Antd 用
babel-plugin-import（已经配了，但按需后还有 300KB）；Monaco Editor做懒加载（但用户进入代码编辑器页面才加载，首屏其实不加载）。保守估计，要两周。
不拆的话，老板那边过不去。但你算了算，这两周的时间成本，够开发一个完整的新功能了。
思考方向：性能优化有个"边际效应递减"的规律------前 80% 的优化可能只用 20% 的时间（压缩图片、开启 Gzip、配好缓存），剩下 20% 的优化要花 80% 的时间（拆包、重写算法、用 WASM 替换）。你的时间成本谁来付？用户体验和开发体验，哪个更值钱？
你需要问自己：
- 这 2 秒的差距，真的会影响用户转化率吗？有数据支持吗？
- 如果把这两周的时间拿去开发新功能，哪个 ROI 更高？
- 那些"最佳实践"的优化，真的适合你的场景吗？比如，对于后台系统，用户真的在乎首屏 0.5 秒的差异吗？
一条可用的标尺：
- 核心路径（登录、支付、主要内容加载）死磕性能------因为这些场景的卡顿直接损失钱
- 非核心路径（帮助文档、用户头像编辑、配置页面）保证可用即可------慢一点用户不会跑
- 用数据说话：先埋点测量，再决定哪里值得优化。80%的性能问题往往出在20%的代码上------找到那 20%
3. 技术规范：统一管控 vs 团队自由
这是一个关于"秩序"与"活力"的平衡。
左边是"统一管控"：代码风格一致，新人上手快，重构成本低。右边是"团队自由"：每个人用自己的方式写代码，创造力不被束缚。
情景 ：你的团队从 2 个人扩张到 8 个人，新来的 6 个人来自不同背景。一个从 Vue 转过来的，习惯写
template；一个从 Angular 来的，喜欢用依赖注入；还有三个应届生，在学校里学的是function和class混着写。
代码 review 时，你们花了半小时讨论"这个组件到底该用函数组件还是类组件""这个函数该叫
handleClick还是
onClickHandler""这个文件该叫index.tsx还是ComponentName.tsx"。你开始考虑要不要把 ESLint 配置写成 500
行，让机器替人吵架。但一个老员工私下跟你说："要是规范太严，我就不想写了------写代码像戴脚镣。"
思考方向：规范的本质是降低认知负担------让团队不用每次讨论"怎么写"。但过度规范本身就是一种认知负担------写代码前先背三天规则。哪边的成本更高？
你需要问自己：
- 机器能解决的问题（代码格式、潜在错误）和需要人判断的问题（命名、设计模式），边界在哪里？
- 统一规范节省的"吵架时间"，和遵守规范消耗的"思考时间"，哪个多？
- 规范的"弹性"该怎么设计？哪些必须死守，哪些可以商量？
一条可用的标尺：
- 自动化能解决的（缩进、分号、未使用的变量）必须强制------这些不需要人判断，机器做更快
- 主观审美的（变量命名风格、组件粒度、文件组织）用指南引导，不强制------给团队留自由空间
- 公共库必须统一（UI 组件库、工具函数库）------否则项目会散架
- 业务代码允许局部风格差异------不同模块可以用不同风格，只要内部一致
4. 技术栈演进：追新 vs 守成
这是一个关于"未来"与"现在"的平衡。
左边是"追新"：用最新的技术，招人容易，开发体验好，但可能踩坑。右边是"守成"：用稳定的技术，不出错，但可能错过趋势。
情景：你维护着一个用 Vue 2 写了三年的后台项目，稳定运行，没人抱怨。最近招了个新人，第一天就问："咱们什么时候升 Vue 3？现在谁还用 Vue 2 啊？" 另一个老同事说："升什么升，跑得好好的，升出 bug 谁负责？"
你去查了查，Vue 3 的生态已经成熟，Composition API 确实能解决很多老代码里的逻辑复用问题------现在那些
mixin已经乱成一团了。但升级意味着：要重写 30% 的代码，要重新培训整个团队，要测试所有功能，要处理第三方库的兼容问题。保守估计，要一个月。
思考方向：技术栈的"保鲜期"越来越短，但业务的"寿命"可能更长。你为"技术时髦度"付出的成本，能从业务收益里赚回来吗？如果 3.0 刚踩完坑，4.0 又出来了，你跟不跟？
你需要问自己：
- 新技术的收益是什么？开发效率提升 20%？性能提升 30%？招聘更容易？这些收益能量化吗？
- 升级的成本是什么？开发工时、测试工时、潜在 bug、团队学习成本------能算出来吗？
- 如果现在不升级，一年后技术债会更难还吗？还是说，可能根本不需要还（项目生命周期快结束了）？
一条可用的标尺：
- 业务价值导向：新技术能带来明显的业务收益（性能提升 50%、开发效率翻倍、招聘竞争力提升）才考虑
- 渐进式引入：不搞"推倒重来"------在老项目旁边起一个新服务，用新栈写边缘功能，验证可行再扩散
- 算学习成本账：学习曲线占用的工时，能否在半年内通过效率提升赚回来？
- 技术债要还，但别急着还：如果项目还有 3 年生命周期，现在升级值得；如果只剩 6 个月，别动
5. 组件设计：通用抽象 vs 简单粗暴
这是一个关于"复用"与"简单"的平衡。
左边是"通用抽象"：写一次，用十次，但设计和维护成本高。右边是"简单粗暴"：针对当前需求写，快，但以后可能重复劳动。
情景：产品经理拿着新需求来找你------要做个"多功能表格"，支持排序、筛选、分页、行内编辑、列拖拽、导出 Excel、列冻结、树形数据、合并单元格。你看了眼时间，两周。
你开始纠结：是写一个"万能表格"组件，把所有功能抽象成配置项，一劳永逸？还是针对这个需求硬编码，先上线再说？
写万能表格：你要设计配置 Schema，要处理所有功能的组合状态，要考虑未来可能出现的 20
种新需求。写下来可能要三周，但以后每次需求来了，改几行配置就行。
硬编码：两周能写完，但下次需求来了，可能要重写 50%。而且产品说"这个表格以后很多页面都要用"。
思考方向："抽象"这个词听起来高级，但它的成本是未来的可维护性。抽象得太早，你可能根本不知道哪些配置真正需要，最后写出一个"覆盖了所有可能但没人用得懂"的怪物；抽象得太晚，你可能已经在 30 个文件里复制了同一段代码，改个样式要改 30 遍。什么时候该赌一把？
你需要问自己：
- 你有多了解未来的需求？如果完全不知道，抽象就是在猜
- 抽象的"投入产出比"是多少？多花一周写的通用组件，未来能省几周？
- 你能承受"写错了"的代价吗？如果抽象错了，重构的难度有多大？
一条可用的标尺：
- 三次原则：同一模式出现三次，才考虑抽象------这是 Kent Beck 的老规矩，但至今有效
- 业务隔离：通用组件（按钮、弹窗、输入框）放公共库，业务组件（用户卡片、订单列表、统计图表）就近维护------业务变化快，别耦合
- 渐进抽象：先复制，再抽离，别一开始就想"一劳永逸"------复制三次后，你自然知道哪些该抽象
6. 代码质量：完美主义 vs 业务交付
这是一个关于"理想"与"现实"的平衡。
左边是"完美主义"：代码整洁，架构清晰，没有技术债，看着舒服。右边是"业务交付"：按时上线，抢占市场，先活下来再说。
情景 ：明天要上线了，你看着代码里还有三个"TODO"没处理。一个是要重构的支付回调函数，逻辑跑通了但写得像屎山------500 行，if 嵌套了 8 层，变量名全是
data1、data2；一个是样式没对齐的按钮，在 1080p 下看着没问题，但在 4K 屏幕上偏移了2px；还有一个是没覆盖的边界情况，用户如果连续点击 10 次提交按钮，可能会重复下单（概率极低）。
产品说"先上，有问题再修"。你知道他说得对------晚一天上线可能损失几十万流水。但你也知道，那个"屎山"以后可能再也没人动了；那个 2px
的偏移，用户可能根本注意不到；那个连续点击的问题，可能一年都不会触发。
思考方向：技术债像信用卡------可以先刷，但要还。问题是：你刷的每一笔，都记在账上了吗？你知道什么时候该刷，什么时候不该刷吗？
你需要问自己：
- 这个技术债的"利息"有多高？屎山的利息是"以后改需求时想死"，2px 偏移的利息是"没人care"，重复下单的利息是"可能会赔钱"------哪个更高？
- 你打算什么时候还债？下个版本？下个月？还是"以后再说"？
- 你有"债务看板"吗？还是说，债欠着欠着就忘了？
一条可用的标尺：
- 核心路径零容忍：支付逻辑、数据一致性、安全漏洞必须完美------这些出问题直接损失钱
- 边缘路径可妥协：低概率边界、样式问题、非核心功能可标记 TODO 后上线------但要记下来
- 有债必还：技术债记在"债务看板"上，排期偿还------每个版本拿出 20% 的时间还债
- 区分"坏债"和"好债"：为了赶上线欠的债是"好债"（有明确还款计划），因为懒欠的债是"坏债"（永远不还）
平衡不是找中点，而是学会踩跷跷板
写到这里，你可能已经发现了：这六个支点其实不是孤立的，它们都在问同一个问题------"在这个时间点，什么更重要？"
项目初期，你可能要偏向效率（快速验证），这时候"追新"和"简单粗暴"反而是对的，因为你还不知道产品能不能活下来；
项目中期，你需要偏向规范（控制熵增），这时候"统一管控"和"通用抽象"开始变得重要，因为团队大了，代码不能乱；
项目后期，你只能偏向稳定（谨慎变更），这时候"守成"和"完美主义"才是安全的，因为用户已经离不开，改错了就完了。
平衡不是找中点，而是学会踩跷跷板------知道什么时候该往哪边倾斜，也知道什么时候该调回来。更重要的，是知道"现在是什么阶段"。
而且你会发现，这些跷跷板的"支点"是会移动的。去年你觉得重要的，今年可能不那么重要；这个项目上对的，下个项目上可能错。
所以，别想着找"标准答案"。标准答案不存在。你能做的，是每次做选择的时候，多问自己一句："我现在踩的是哪条跷跷板？我往哪边倾斜？我能调回来吗？"
写在最后
回到开篇那个问题：什么时候该自己写，什么时候该用库？
其实答案和所有其他问题一样：看情况。
但如果有一条红线可以帮你判断，那就是------如果这个功能是你项目的核心差异化优势，就自己写；如果不是，就用库。
至于什么是"核心差异化优势"，那是另一个需要平衡的问题------可能是性能，可能是体验，可能是开发速度，可能是技术品牌。你得自己踩那个跷跷板。
你在项目里踩过哪些"失衡"的坑？欢迎评论区分享，一起聊聊那些年我们做过的"技术选型后悔药"。