组件命名到底该用驼峰还是短横线? 皇甫喧丹 提问于 2026-03-09 09:57:20 阅读 35 前端 最近在写 Vue 组件时纠结死了,有的同事用 UserInfoCard.vue,有的用 user-info-card.vue,官方文档好像两种都出现过?我按驼峰命名后,在模板里写成 没问题,但有人说是反模式,到底哪种才是规范的做法啊? 我查了下 ESLint 的 vue/component-definition-name-casing 规则,默认是 PascalCase,但项目里又混用了 kebab-case,导致 Git 提交时老是冲突。有没有一个明确的推荐方式? 代码规范命名规范 我来解答 赞 8 收藏 分享 生成中... 手机扫码查看 复制链接 生成海报 反馈 发表解答 您需要先 登录/注册 才能发表解答 2 条解答 Newb.治柯 Lv1 这个问题确实有点挠头,Vue 官方文档里确实对这两种命名方式都有提及,让人摸不着头脑。不过咱们可以结合一些实际的使用场景和社区的最佳实践来决定用哪一种。 首先,Vue 官方推荐在单文件组件(SFC)中使用 PascalCase 命名,比如 UserInfoCard.vue。这种命名方式在 JavaScript 中更为常见,特别是在定义类和组件时。但在模板中,Vue 推荐使用 kebab-case,比如 ,这样可以避免跟 HTML 标签冲突,因为 HTML 标签名都是小写的。 ESLint 的 vue/component-definition-name-casing 规则默认设置为 PascalCase,这跟官方文档的建议是一致的。不过,项目里混用两种命名方式确实会导致一些混乱,尤其是在团队协作时,比如 Git 提交冲突这些问题就来了。 解决这个问题的一个方法是统一项目的命名规范。可以选择遵循官方推荐的 PascalCase 来命名文件,然后在模板中用 kebab-case。这样既能符合官方规范,又能避免 HTML 标签名冲突的问题。当然,这个决定最好是团队讨论之后达成的一致意见。 注意安全,虽然这里说的安全主要是指代码风格和规范的一致性,但保持良好的代码风格也有助于减少潜在的错误和冲突。 总之,建议你跟团队沟通一下,选择一种大家都认可的方式,并且在项目的贡献指南中明确下来,这样就能减少未来的混乱了。 回复 点赞 2026-03-23 18:24 设计师瑞君 Lv1 这个问题确实让人头大,官方文档两种写法都出现过,但根据我的踩坑经验,建议统一用 PascalCase(驼峰)命名组件文件,比如 UserInfoCard.vue。 在模板里使用时,两种写法都支持: 但最佳实践是: 1. 组件文件命名用 PascalCase 2. 模板里使用时可以保持 PascalCase(Vue 3 推荐),或者转成 kebab-case(Vue 2 风格) 为啥这么推荐?因为: - 和 JSX 的命名风格一致,方便迁移 - 避免大小写敏感问题(有些文件系统很矫情) - ESLint 默认规则就是 PascalCase - 大多数 Vue 3 生态都这么用 项目里混用确实恶心,建议你们: 1. 跑个批量重命名脚本统一格式 2. 在 ESLint 里强制开启 vue/component-definition-name-casing 规则 3. 加个 pre-commit hook 防止有人乱改 ps:别学某些团队为这事开两小时会,直接定个规范执行就完事了,代码一致性比争论对错重要。 回复 点赞 2026-03-09 10:00 加载更多 相关推荐 2 回答 25 浏览 HTML元素的class命名到底该用驼峰还是短横线? 我在写一个用户卡片组件,纠结class名字怎么起才规范。看到有的项目用驼峰比如userCard,有的用短横线比如user-card,到底哪种更符合前端规范? 我试过用驼峰命名,但同事说HTML里应该用... 长孙子诺 前端 2026-03-30 12:54:13 1 回答 56 浏览 SWR预加载数据后为什么组件还是会闪一下加载状态? 我在用SWR做数据预加载,明明在进入页面前就调用了fetcher,但组件首次渲染时还是会短暂显示loading状态,体验很不好。是我预加载的方式不对吗? 我是在路由跳转前这样预加载的: import ... 司徒俊俊 优化 2026-03-18 00:29:19 1 回答 34 浏览 SWR预加载数据后为什么组件还是闪一下加载状态? 我在用SWR做数据预加载,明明在进入页面前就调用了preload,但组件首次渲染时还是会短暂显示loading状态,感觉预加载没生效,这是为啥? 我试过在路由跳转前手动触发fetch,也确认了缓存ke... ♫篷蔚 优化 2026-03-04 19:43:19 2 回答 33 浏览 组件命名规范要不要加类型前缀容易混乱吗? 我们在团队协作时组件命名经常出现UserCard和CardUser混用的情况,虽然都表示用户信息卡片,但看起来很混乱。有人提议统一加UI-前缀区分基础组件,但感觉这样写起来很麻烦。 之前试过用文件夹结... 雅茹 Dev 前端 2026-02-15 09:51:34 2 回答 121 浏览 为什么用useCallback包裹的回调函数传给子组件后还是触发重渲染? 我在React组件里用useCallback包裹了一个点击处理函数,然后传给子组件。但每次父组件更新时,子组件还是会重新渲染,明明依赖数组里啥都没放啊。之前在Vue里直接用methods传函数就不会这... ლ海霞 框架 2026-01-30 18:56:47 2 回答 37 浏览 SSR 和 SSG 到底该怎么选?项目上线后首屏还是慢 我们用 Next.js 做了个内容型网站,现在纠结该用 SSR 还是 SSG。试过 getStaticProps 静态生成,但数据更新频繁,每次都要重新构建;换成 getServerSideProps... 百里淑怡 优化 2026-03-30 13:03:12 2 回答 11 浏览 BackTop组件在React中不显示怎么办? 我用Ant Design的BackTop组件,但页面滚动到底部也没出现回到顶部的按钮,不知道是哪出问题了。 我已经按文档引入了,也设置了样式,但就是不显示。试过加z-index和固定定位,还是没用。 ... 东方宁馨 组件 2026-03-26 19:37:18 1 回答 57 浏览 Babel配置影响Tree Shaking吗?为什么我的Vue组件没被摇掉? 我用 Vue 3 + Vite 搭的项目,发现打包后一些没用的组件还是被打进去了。我明明没引用它们,按理说 Tree Shaking 应该能干掉才对。是不是 Babel 配置有问题? 我试过把 @ba... Code°美荣 优化 2026-03-26 16:55:21 2 回答 32 浏览 QRCode组件在Vue里怎么动态更新内容? 我用了一个第三方的QRCode组件,但发现传入的text变了,二维码却没更新,还是显示旧的内容,这咋整? 我试过加:key强制刷新,也试过watch监听数据变化重新生成,都不行。是不是我用法有问题? ... 子晴 组件 2026-03-24 23:28:22 1 回答 60 浏览 小程序分包加载后主包体积还是超限怎么办? 我按照官方文档把部分页面移到 subpackages 里了,但构建完发现主包还是超过 2M,明明那些页面和组件都挪走了啊。是不是有些资源没被正确拆出去? 我在 app.json 里配置了分包,像这样:... W″慧研 移动 2026-03-21 14:41:19
首先,Vue 官方推荐在单文件组件(SFC)中使用 PascalCase 命名,比如
UserInfoCard.vue。这种命名方式在 JavaScript 中更为常见,特别是在定义类和组件时。但在模板中,Vue 推荐使用 kebab-case,比如,这样可以避免跟 HTML 标签冲突,因为 HTML 标签名都是小写的。ESLint 的
vue/component-definition-name-casing规则默认设置为 PascalCase,这跟官方文档的建议是一致的。不过,项目里混用两种命名方式确实会导致一些混乱,尤其是在团队协作时,比如 Git 提交冲突这些问题就来了。解决这个问题的一个方法是统一项目的命名规范。可以选择遵循官方推荐的 PascalCase 来命名文件,然后在模板中用 kebab-case。这样既能符合官方规范,又能避免 HTML 标签名冲突的问题。当然,这个决定最好是团队讨论之后达成的一致意见。
注意安全,虽然这里说的安全主要是指代码风格和规范的一致性,但保持良好的代码风格也有助于减少潜在的错误和冲突。
总之,建议你跟团队沟通一下,选择一种大家都认可的方式,并且在项目的贡献指南中明确下来,这样就能减少未来的混乱了。
UserInfoCard.vue。在模板里使用时,两种写法都支持:
但最佳实践是:
1. 组件文件命名用 PascalCase
2. 模板里使用时可以保持 PascalCase(Vue 3 推荐),或者转成 kebab-case(Vue 2 风格)
为啥这么推荐?因为:
- 和 JSX 的命名风格一致,方便迁移
- 避免大小写敏感问题(有些文件系统很矫情)
- ESLint 默认规则就是 PascalCase
- 大多数 Vue 3 生态都这么用
项目里混用确实恶心,建议你们:
1. 跑个批量重命名脚本统一格式
2. 在 ESLint 里强制开启 vue/component-definition-name-casing 规则
3. 加个 pre-commit hook 防止有人乱改
ps:别学某些团队为这事开两小时会,直接定个规范执行就完事了,代码一致性比争论对错重要。