语义化提交规范中，新功能、设计、更新是否统一使用feat类型？

不需要把所有前端改动都套上feat:，严格对照你梳理的规范定义卡边界即可：

• 开发新功能场景：只有改动属于面向用户可感知的新增交互、能力点（比如新增购物车结算的优惠券抵扣逻辑、新增全局搜索入口），才符合feat:的适用要求。纯构建脚本、测试代码的新增改动，不算feat:范畴。
• 设计调整场景：绝大多数纯视觉类设计调整不能使用feat:。如果改动只是调整现有页面的间距、配色、圆角，没有新增交互逻辑、没有给用户提供新的能力，这类改动不属于新功能范畴。
• 常规版本更新场景：比如升级前端依赖版本、同步版本号配置、调整CDN资源路径这类常规更新，属于chore:类改动，和用户可感知的新功能无关，完全不需要用feat:。

• 行业通用的语义化提交核心约定来自Conventional Commits规范，这套规范本身不强制要求只能使用固定的7种提交类型。只要满足两个前提，自定义类型就是合规的：
  • 自定义类型的语义边界清晰，不会和现有核心类型的适用场景产生混淆
  • 自定义类型提前在项目的贡献规则、提交校验配置里明确说明，团队所有成员对类型的适用场景有统一认知
• 针对你提到的两类自定义类型的实际判断：
  • design:：属于实用性很强的合规自定义类型，专门用来归类纯视觉设计调整类的改动——比硬套原有体系里的style:更精准，因为传统style:的定义是不改变生产逻辑、不改变视觉呈现的代码风格类调整（比如补分号、统一缩进），把纯设计类的视觉改动单独拆出design:类型，是很多成熟前端团队的实际落地做法。
  • update:：不建议作为通用提交类型使用，因为语义过于模糊——升级依赖是update、修改页面文案是update、修复线上bug也是update，完全无法通过提交类型快速判断改动的影响范围，会直接失去语义化提交的核心价值。

• 不要无限制扩展自定义提交类型，避免出现“为了一个小改动单独加一个提交类型”的冗余情况。大部分细分场景可以通过「核心提交类型+改动范围标注」的方式实现区分，比如fix(home): 修复首页设计调整后按钮错位的问题，不需要单独加fix-design:这类冗余类型。
• 所有自定义类型必须同步到项目的提交校验规则（比如commitlint配置）里，不然容易出现自动化发版流程识别错误——比如本该触发次版本升级的feat:改动，被模糊的update:标记后，发版工具识别不到，会导致版本号计算错误。

内容的提问来源于stack exchange，提问作者seongkuk han