驼峰方式: api/getList
中划线： api/get-list
哪种方式使用的多些， 记得以前 seo 为王的年代，"-"中划线方式是不被推荐作为域名或者 path 的
现在 seo 已经淡出视野，不知道大家是怎么设计的
第 1 条附言 · 9 天前
感谢大家的分享，的确是中划线（减号，短横线）更加合理些。
 |
1
superrichman 9 天前
下划线: get_list
|
 |
2
kokerkov 9 天前
WSJ 和路透社都是“-”
|
 |
3
flmn 9 天前  3
我怎么记得之前一直推荐的就是"-"中划线方式呢？
我个人选择中划线，理由： 1 、不用驼峰，这样 url 里全小写，统一好看，如果是别人敲字，也不用考虑大小写 2 、下划线跟空格视觉区分度差 3 、传统的网站，讲究的也是中划线区分单词 |
 |
4
cksspk 9 天前
我也是推荐 "-" 中划线，看着舒服点
|
 |
5
elltor 9 天前
虽然「-」比较推荐，但是（我们）项目里用的不多，主要原因是「-」分割的 path 不利于前端生成 api model （ ts 根据 swagger 生成 ts 类那一套）
|
 |
6
shenyangno1 9 天前
记忆中一直是推荐的是中划线
|
|
7
superrichman 9 天前
|
 |
8
hanssx 9 天前
路径 url 属于显示方面，肯定中线，getList 是省字符的方式，我只会考虑编码时使用，另外中线这玩意儿在显示方面叫 slug 。
|
 |
9
chendy 9 天前 3
下划线，双击复制粘贴的时候下划线能一起选到，中划线会被切断
不用驼峰是为了避免潜在的大小写敏感不敏感问题 |
 |
10
Vegetable 9 天前 7
个人来说
不建议在 url 中使用大小写敏感的路径。很少见，不好看。 整个 http 协议里边，大小写这块都不统一。scheme/host/header 都是大小写不敏感的，但是 path/query/body 又是敏感的。为了统一直接全部小写。 不建议使用下划线，因为 header 中下划线存在一些历史问题，Nginx 默认都是不支持的，为了避免麻烦保持一致性，统一使用-。 |
 |
11
lveye 9 天前
我司参考的是 google 的 AIP （ https://google.aip.dev/136 ），它的多字母自定义动词是要求与 rpc 的方法名保持一致，即小驼峰。但是我领导看不惯这种写法，这种格式都统一用的中横线
 |
 |
12
bv 9 天前
|
 |
13
nthin0 9 天前
推荐是中划线，我司因为历史包袱一直用的下划线
|
 |
15
hanierming 9 天前
推荐还是中划线，下划线在域名中是不能使用的，但是 path 可以，所以感觉还是中划线好点
|
 |
16
newaccount 9 天前
驼峰式：遇到有人写错查的时候坑死你，大 I 小 L 就够把你压箱底儿的大刀抽出来了
下划线：下划线不能用在域名里面，你确定要时刻记着什么地方可以用什么地方不能用吗 横线：看着前面两条懒得说话 |
 |
17
sunny2580839896 9 天前 1
最近正好在设计这块，也是很纠结，综合结论就是：ai 推荐 a-b 这种命名，但是编辑器 a-b 复制会截取，所以使用 a_b ，但是，但是，微信回调必须是 xx.com/a/b 这种形式，最后项目就变成了这 3 种形式都有的组合
|
 |
18
bitmin 9 天前
我喜欢中划线，好输入好看
下划线和驼峰都属于不好输入不好看 |
 |
19
nilaoda 9 天前
考虑被搜索引擎抓取，就用中划线-
否则就用下划线_ 驼峰是下下策 |
 |
20
Zenon 9 天前
呃，下划线
|
 |
22
mxT52CRuqR6o5 9 天前 via Android
ai 时代用下划线中划线更好些？有利于 llm 分割 token
|
 |
23
kaf 9 天前
下划线看不清，中划线比驼峰好看
|
 |
24
pigf 9 天前
减号
大家以后也叫中划线为为减号吧 |
 |
25
kingterrors 9 天前
@sunny2580839896 如果只是编辑器不适应，编辑器配置一下对应的设置，让下划线能直接选中就好了。
|
 |
26
jingdongkehu 9 天前
全小写尽量一个词，一个词不行就简写
|
 |
27
CoderLife 9 天前
GET: api/shop/list
GET: api/shop/info POST: api/shop/save |
 |
28
oukichi 9 天前
绝对是中划线，没别的选，甚至没有多想的必要，真的
|
 |
29
Cyron 9 天前
如果是前端，URL 友好格式是用 dash （-）分割
如果是后端 api ，打开 github 看看 fetch 请求你就懂了 |
 |
30
x86 9 天前
中划线看着都舒服很多了
|
 |
31
acthtml 9 天前
肯定连词线啊。
从古至今，path 中是否带有连词线，对 seo 都没有影响。 |
 |
32
guanhui07 9 天前
下划线 方便复制
|
|
33
sunny2580839896 9 天前
@kingterrors 好的，谢谢大佬
|
 |
34
salmon5 9 天前
|
 |
35
vivisidea 9 天前 1
优先考虑不加线
/api/getList --> /api/list 非加不可的话，个人倾向于 中划线 /api/get-list 切换大小写打字很烦 |
 |
36
qsnow6 9 天前
拒绝反人类的大小写，遇到近似字符简直抓狂，还有部分客户端可能会自动转换为全小写，最佳实践就是全小写。
|
 |
37
wangyzj 9 天前
rest 方式尽量用资源分层写法，不需要中划线啥的
如果有些特殊不得不，那么中划线 |
 |
38
hydrionz 9 天前
公司里大部分都在用驼峰形式，但是这个东西有时候一个大小写没注意就 404 了，尤其当前端对自己眼睛比较自信，不复制而自己手打的时候
下划线没法申请域名，所以 URL 中其他地方我也都没用过下划线 自己平时定义 URL 用中划线比较多，个人域名也是两个字母中间一个中划线 |
 |
39
eBMm8zIi0Zq3 9 天前
驼峰好像对有些设备软件兼容不行，会有忽略大小写的情况。
|
|
40
eBMm8zIi0Zq3 9 天前
我指的是 URL 中的驼峰
|
 |
41
fuyun 9 天前
难道不应该是 GET /api/posts 吗？为什么还要多此一举/api/get-posts ？
 |
 |
42
Ipsum 9 天前 via Android
Restful 应该不存在这个问题，都用 method 动词代替了。
|
 |
43
auh 8 天前
/apis
get 是 http 方法。s 代表 list 。 |
 |
44
iseki 8 天前
我更喜欢 M$ 的 API 风格指南，该指南推荐中划线。我猜想这可能和 HTTP 协议的整体风格有关。
|
 |
45
spritecn 8 天前
这取决于用 java 还是用 python 吧,java 大家都写驼峰,python 都是蛇
|
 |
46
zhyt1985 8 天前 1
url 里不能有动词啊，应该是/api/list
|
 |
47
zhangdp 8 天前
restful ，不要 get ，就是/api/list 简单明了
|
 |
48
julyclyde 8 天前
seo 为王的年底啊，大家都把 seo 当 sb 伺候？
|
 |
49
SunnyIng 8 天前
|
 |
50
yjw06282 7 天前
用 next.js 怎么办. url 是目录自动生成的. 目录总要驼峰合适吧
|
 |
52
Aresxue 1 天前
感谢 DeepSeek-R1 和 GPT 4o ，以下为当前页面的总结
### **中划线（-）** **优点** 1. **视觉友好** - 无驼峰大小写混淆（如 **`i`** 和 **`l`** 视觉近似问题） - 空格替代感强，单词分隔清晰（**`get-list`** vs **`get_list`**） 2. **技术兼容性** - 与域名规范一致（域名不支持下划线） - 避免 HTTP 协议中路径大小写敏感问题（全小写统一） - 符合 Google SEO 推荐（[**官方文档**]( https://developers.google.com/search/docs/crawling-indexing/url-structure)），传统网站和 SEO 实践中，多推荐使用中划线 3. **输入便捷性** - 无需切换大小写，打字效率更高 - 符合传统网站习惯（如 **`about-us`**、**`contact-info`** **缺点** 1. **前端工具兼容性** - 使用 **`-`** 分割路径可能导致 TS 模型生成工具解析困难（需额外配置） - 某些自动生成的 API 工具不便生成含中划线的路径 2. **复制粘贴体验** - 在某些编辑器中，双击选中时，中划线可能被切断（依赖编辑器配置修正），导致不易选中整个字符串。 ### **下划线（`_`）** **优点** 1. **开发工具友好** - 双击复制时，下划线会被整体选中（无需配置编辑器） - 与部分编程风格（如 Python 的 **`snake_case`**）一致 2. **规避大小写问题** - 全小写下划线无大小写敏感风险 **缺点** 1. **视觉与功能性争议** - 下划线在长 URL 中与空格区分度低（如 **`get_list`** vs **`getlist`**），可能与空格混淆 - 域名不支持下划线，路径中混用可能引发混淆 2. **服务器配置风险** - Nginx 等服务器默认不支持 URL 中的下划线（需手动启用） ### **驼峰** **优点** 1. **开发友好性** - 与后端代码风格（如 Java 的驼峰命名）高度一致 - 节省字符长度（如 **`getList`** vs **`get-list`**） **缺点** 1. **用户体验风险** - 手动输入易混淆（如 **`i`** vs **`L`**） - 部分客户端可能自动转全小写导致 404 - **输入不便**：需要在输入时切换大小写，使用上稍显麻烦 2. **协议兼容性问题** - HTTP 路径大小写敏感，需严格匹配（前端/运维易出错） 总的来说，选择哪种格式需考虑具体应用场景的约束和需求，如 SEO 友好性、开发工具兼容性、团队编码规范等。中划线在较多场合被优选，尤其是在 SEO 和 URL 命名中。 |
 |
53
simenet 1 天前
[_]
|
Select Language