target版本选择前必须做的3步需求拆解
很多人选target版本时，要么跟风选最新的，要么凭感觉选熟悉的，其实这都是没做好需求拆解。就像你去买衣服，不先知道自己穿多大码、喜欢什么风格，再好看的衣服也可能不合身。target版本选择也是一样，选之前这3步拆解你一定要做，少一步都可能出问题。
第一步：用“核心功能锚定法”明确必选需求
你得先搞清楚，这个项目最核心的功能是什么？哪些功能是“没它不行”的，哪些是“有它更好”的。比如你做一个数据可视化项目，需要用到Canvas或SVG的高级动画，那target版本就不能太低，至少要支持这些API；但如果只是做一个静态展示页面，核心功能就是“显示文字和图片”，那target版本就可以灵活很多。
我之前带过一个电商项目，核心功能是“商品列表展示+购物车操作”，团队一开始想选ES6+作为target版本，觉得写起来效率高。我让他们先列核心功能依赖的API，结果发现购物车的本地存储用localStorage就行，商品列表渲染用基本的DOM操作，这些ES5都支持，最后选了ES5+，不仅打包体积小了20%，兼容性也更好。所以你看，明确核心功能依赖的API，是选对target版本的第一步，这一步做扎实了，后面就不容易跑偏。
第二步：用“用户画像分析法”锁定设备边界
你肯定遇过这种情况：自己电脑上测试没问题，用户一用就出bug。其实问题往往出在没搞清楚你的用户在用什么设备。不同行业、不同人群的用户，设备和浏览器版本差异大到你想象不到——比如做toB项目，企业用户可能还在用几年前的办公电脑和IE浏览器；做toC的年轻人项目，大部分用户都是最新的Chrome或Safari。
我通常会让团队用这两个工具分析用户设备：一是百度统计或Google Analytics，直接看现有用户的浏览器版本分布（如果是新项目，可以参考同行业数据）；二是Can I Use（https://caniuse.com/，nofollow），查目标API在各浏览器的支持情况。去年我帮一个政务类项目选target版本，一开始按常规思路考虑，结果甲方提供的用户数据显示，45%的用户浏览器版本低于Chrome 60，最后只能把target版本降到ES5，还专门加了polyfill处理，才没出问题。所以你选target版本前，一定要花1-2天时间做用户设备分析，别凭感觉拍脑袋。
下面这个表格是我整理的不同类型项目用户设备分析参考，你可以对照着看：
| 项目类型 | 主流浏览器 | 最低支持版本 | 推荐target版本 |
|---|---|---|---|
| toC年轻用户 | Chrome/Safari/Edge | 近2年版本 | ES6+ |
| toB企业用户 | IE/Chrome旧版 | IE11+/Chrome 55+ | ES5+ |
| 移动端H5 | 微信/手机自带浏览器 | iOS 12+/Android 8+ | ES6+（配合Babel） |
第三步：按“项目周期倒推法”预留迭代空间
你可能会说，需求和用户都分析清楚了，选版本不就简单了？其实还不够，项目周期也是个关键因素。如果你的项目是短期项目，比如一个活动页，上线后只维护1-2个月，那target版本可以激进一点，甚至用最新的特性，反正后面不用长期维护；但如果是长期项目，要维护2年以上，那就要考虑 的功能迭代——选太旧的版本，后面想加新功能可能要重构，选太新的版本，万一后面浏览器支持变化，维护成本也会很高。
我之前带过一个SaaS产品，计划维护3年，一开始选了ES2018作为target版本，觉得功能全。结果第二年要加一个低代码编辑器功能，需要用到ES2020的动态import，旧版本不支持，只能用Webpack的require.ensure做兼容，多花了不少时间。后来复盘时发现，如果当时选ES2019，既能支持大部分新功能，又不会太激进，维护起来会更轻松。所以你选target版本时，一定要想想项目 1-2年的迭代计划，给自己留一点“技术缓冲带”，别只看眼前。
3个维度帮你精准锁定最优target版本
需求拆解清楚后，接下来就是具体选版本了。这一步就像挑水果，要从“新鲜度”“口感”“价格”多个角度看，target版本也一样，得综合兼容性、功能覆盖、维护成本这3个维度，才能选到“性价比最高”的那个。
维度一：兼容性——用“木桶原理”找最低短板
兼容性绝对是target版本选择的“红线”，就像木桶装水，最短的那块板决定水量，用户设备里占比再低的浏览器版本，只要存在，你就不能完全不管。这里有个小技巧：不用追求“支持所有浏览器”，而是找到“可接受的最低支持版本”——比如某个浏览器版本占比低于1%，且用户群体不是核心付费用户，那就可以考虑放弃支持，毕竟为了1%的用户牺牲99%用户的体验，性价比太低。
怎么判断“可接受的最低支持版本”？我通常会结合两个数据：一是用户浏览器版本的占比（比如用前面说的百度统计），二是该版本对核心功能API的支持情况（查Can I Use）。举个例子，如果你核心功能要用Array.prototype.includes，查Can I Use发现IE11不支持，而IE11用户占比5%，这时候你有两个选择：要么把target版本提高到支持includes的版本（比如Chrome 47+），放弃这5%的用户；要么降低target版本，用polyfill兼容IE11。怎么选？看这5%的用户对你的项目有多重要——如果是付费用户，那必须兼容；如果是普通浏览用户，且项目预算紧张，就可以考虑放弃。
维度二：功能覆盖——避免“为了一棵树放弃整片森林”
选target版本时，很容易陷入“功能洁癖”——看到新特性就想用，结果选了过高的版本，反而影响整体项目进度。其实功能覆盖不是“越多越好”，而是“够用就好”。我 了一个“功能必要性打分表”，你可以试着给每个想用到的新特性打分（1-5分，1分“可有可无”，5分“必须要有”），最后总分低于10分的，完全可以用旧版本+polyfill解决，没必要为了这些功能提高target版本。
比如我之前有个项目，团队想用上ES2020的optional chaining（?.），觉得写起来方便。我让他们打分，结果这个功能最多算3分（“用起来方便，但不用也能实现”），最后用babel-plugin-transform-optional-chaining插件在ES5环境下实现了，既没提高target版本，又用上了想要的功能。所以你看，很多新特性都有替代方案，不一定非要通过提高target版本来实现，别让“想要某个功能”变成你选择版本的唯一理由。
维度三：维护成本——算清楚“长期账”
选target版本时，很多人只看“现在好不好写”，忽略了“以后好不好维护”。其实维护成本才是长期项目最该考虑的——太旧的版本，可能社区停止维护，遇到bug没人解决；太新的版本，团队成员不熟悉，学习成本高，而且可能有未知的坑。
这里有个小 优先选择“LTS版本”（长期支持版本），比如Node.js的LTS版本，或者浏览器的稳定版，这些版本通常有2-3年的维护周期，bug修复及时，社区资源也多。我之前有个项目选了一个刚发布半年的浏览器版本作为target，结果上线后发现一个隐藏的渲染bug，官方迟迟不修复，最后只能自己写hack解决，折腾了好久。要是当时选LTS版本，就不会遇到这种问题了。
还要考虑团队的技术栈匹配度——如果团队大部分人对TypeScript不熟，你非要选需要TypeScript 4.5+支持的target版本，那团队学习成本会很高，反而拖慢项目进度。所以选版本时，别忘了“以人为本”，让团队能轻松上手，比追求“技术先进性”更重要。
你最近有没有遇到target版本选择的问题？或者有什么自己的小技巧？欢迎在评论区告诉我，我们一起讨论～
你知道吗？很多人一提到target版本就觉得“越新越好”，就像买手机非要追最新款，结果发现很多功能根本用不上，还多花了冤枉钱。target版本选择其实也是一个道理——最新版本虽然堆了很多新特性，比如更简洁的语法、更强大的API，但这些东西对你的项目来说，可能就像智能手机的“卫星通话功能”，普通人日常根本用不上，反而要承担它带来的兼容性风险和团队学习成本。
我之前见过一个团队，做一个内部管理系统，非要用当时刚出的ES2022作为target版本，觉得“技术领先有面子”。结果写了半个月，发现团队里一半人还没搞懂Top-level await怎么用，加上公司老电脑的浏览器不支持，最后不仅开发效率低，上线后还因为兼容性问题改了又改。后来他们换成ES6+，反而进度快了不少，代码也更稳定。所以你看，选版本真不是“新就是好”，关键是得先搞清楚你的项目到底需要什么功能，用户在用什么设备，就像给鞋子选尺码，合脚的才是最好的，哪怕它不是最新款。
就拿静态展示类项目来说吧，比如公司官网这种，核心功能就是显示文字、图片和简单的导航，这种项目用ES5+就足够了——你想想，ES5的语法已经能满足DOM操作、样式控制这些基础需求，而且兼容性广，从IE9到最新浏览器都支持，打包出来的代码体积还小，加载速度更快。但如果是做动态交互很强的项目，比如在线协作工具，需要用到Proxy监听数据变化，或者BigInt处理大数字，那target版本就不能太低，得选支持这些API的版本。所以说，“够用且稳定”才是target版本选择的黄金标准，盲目追新反而容易给自己挖坑，你说是不是？
选择target版本时，一定要用最新的版本吗？
不一定。最新版本虽然功能全，但可能存在兼容性风险和团队学习成本。选版本前应先通过“核心功能锚定法”明确必选需求，结合用户设备画像（如ToB项目可能需兼容旧浏览器）和项目周期（长期项目需预留迭代空间），优先选择“够用且稳定”的版本，而非盲目追新。比如静态展示类项目用ES5+可能比最新ES版本更合适，打包体积更小、兼容性更好。
如何判断项目是否需要兼容低版本浏览器？
可通过“用户画像分析法”判断：先收集用户浏览器版本占比（如用百度统计），再结合Can I Use查询核心功能API在低版本的支持情况。若低版本浏览器用户占比低于1%且非核心付费用户，可考虑放弃兼容；若占比高或为核心用户（如ToB企业用户），则需通过降低target版本或用polyfill兼容。例如IE11用户占比5%且为付费用户时， 优先兼容。
target版本选低了，后期想升级怎么办？
分阶段逐步升级，避免一次性重构。先列出当前项目核心功能依赖的新API（如ES6的箭头函数、Promise），用Babel或TypeScript转译工具将高版本语法转为低版本兼容代码；再通过灰度测试验证升级后的兼容性，优先在非核心模块试点，最后扩展到全项目。例如从ES5升级到ES6时，可先在工具类模块试用let/const，验证无问题后再推广到业务逻辑。
用Babel转译后，是不是就不用在意target版本了？
不是。Babel主要解决语法转译（如将ES6箭头函数转为ES5函数），但无法处理API缺失（如Array.prototype.includes、Promise），需搭配polyfill（如core-js）补充。 过度依赖转译可能导致打包体积增大、性能下降。 仍需明确target版本，结合“兼容性维度”评估，确保转译和polyfill的成本低于直接选择适配版本的成本。
ToB和ToC项目的target版本选择有什么区别？
主要差异在用户设备和兼容性要求。ToB项目（如企业管理系统）用户多使用旧设备和浏览器（如IE11、Chrome旧版），需优先兼容稳定性， 选ES5+并搭配polyfill；ToC项目（如年轻人社交应用）用户设备较新（如iOS 12+、Android 8+），可更激进，选ES6+以提升开发效率。例如电商ToC项目用ES6+搭配Babel，既能用新特性又保证移动端兼容性，而ToB后台系统则 用ES5+降低维护风险。
