前端依赖越装越多，版本和许可证都得留个底

一个看起来普通的企业站，前端依赖动辄几百个包。真正写进页面的可能只有几个，剩下全是它们的依赖。平时没人在意，等到构建失败或者客户做安全审查，才发现底账是空的。

锁文件要进版本库

锁文件记录每个包的确切版本与来源，保证不同机器装出来的东西一致。不提交锁文件，等于每次构建都在碰运气：今天能跑，明天换台电脑就报错。

版本范围别放太宽

语义化版本里，主版本号变化意味着不兼容。写成宽松范围，某天自动升到新主版本，构建直接失败。企业站更新频率低，更适合锁死小版本，按计划成批升级，而不是让它自己漂。

传递依赖才是大头

直接依赖看得见，传递依赖看不见。出了漏洞，往往是从某个深层依赖传上来的。定期生成依赖树，把重复的、没人维护的包挑出来，比逐个翻配置文件有效。

许可证要分类看

MIT、Apache、BSD 这类宽松许可，商用一般负担不大，但要保留版权声明；GPL、AGPL 这类传染性许可，用在闭源项目里就要谨慎。前端打包之后算不算分发，需要法务判断，技术侧的责任是把清单交出去，而不是替公司下结论。

扫描与归档

用工具生成许可证清单和软件物料清单，随版本归档。客户做供应商安全审查时，这份清单能省很多来回；出了漏洞，也能快速判断影响哪些站点。

升级要有节奏

小步升级，一次只动一类，升完跑一遍关键页面与表单。攒一年再升，问题会堆在一起，谁也说不清是哪次改动引入的。升级前留一个可回退的构建产物，出问题十分钟内切回去。

没人维护的包

看最近提交时间、问题响应速度、有没有已知漏洞。停更的包尽早找替代，别等到某天构建报错才处理。依赖越少，替换越容易，这条在选型阶段就该想。

小结

依赖管理听起来是工程细节，实际关系到站点能不能长期维护：锁得住版本、看得清来源、说得明许可、退得回旧版。冉冉科技在做站点交付时，会把依赖清单与许可证记录一并交给客户。

关于冉冉科技

江苏冉冉信息科技有限公司（品牌“冉冉科技”）成立于2017年，位于江苏省常州市新北区，是一家从事互联网信息服务、电子商务应用与企业应用系统开发的技术服务企业。公司业务涵盖网站建设、网页设计、SEO优化、竞价包年、域名注册、虚拟主机、企业邮箱、整合营销及企业形象策划等，以“只做有效果的网络营销”为服务主张，累计完成三千余起网站建设与服务。