关于路径 url 的设计，是驼峰方式还是中划线方式用的多些

下划线: get_list

WSJ 和路透社都是“-”

我怎么记得之前一直推荐的就是"-"中划线方式呢？

我个人选择中划线，理由：
1 、不用驼峰，这样 url 里全小写，统一好看，如果是别人敲字，也不用考虑大小写
2 、下划线跟空格视觉区分度差
3 、传统的网站，讲究的也是中划线区分单词

我也是推荐 "-" 中划线，看着舒服点

虽然「-」比较推荐，但是（我们）项目里用的不多，主要原因是「-」分割的 path 不利于前端生成 api model （ ts 根据 swagger 生成 ts 类那一套）

记忆中一直是推荐的是中划线

Youtube 首页 F12 就能看到这个请求
https://www.youtube.com/youtubei/v1/log_event?alt=json
会抄了吧

路径 url 属于显示方面，肯定中线，getList 是省字符的方式，我只会考虑编码时使用，另外中线这玩意儿在显示方面叫 slug 。

下划线，双击复制粘贴的时候下划线能一起选到，中划线会被切断
不用驼峰是为了避免潜在的大小写敏感不敏感问题

个人来说

不建议在 url 中使用大小写敏感的路径。很少见，不好看。

整个 http 协议里边，大小写这块都不统一。scheme/host/header 都是大小写不敏感的，但是 path/query/body 又是敏感的。为了统一直接全部小写。

不建议使用下划线，因为 header 中下划线存在一些历史问题，Nginx 默认都是不支持的，为了避免麻烦保持一致性，统一使用-。

我司参考的是 google 的 AIP （ https://google.aip.dev/136 ），它的多字母自定义动词是要求与 rpc 的方法名保持一致，即小驼峰。但是我领导看不惯这种写法，这种格式都统一用的中横线

推荐使用 “-” 中划线即：连字符。https://developers.google.com/search/docs/crawling-indexing/url-structure?hl=zh-cn#:~:text=%E5%BB%BA%E8%AE%AE%EF%BC%9A-,%E4%BD%BF%E7%94%A8%E8%BF%9E%E5%AD%97%E7%AC%A6,-(%2D)%EF%BC%9A

推荐是中划线，我司因为历史包袱一直用的下划线

@lveye 这两天也在看这个，其中的 custom method 搞得我是懵逼了

推荐还是中划线，下划线在域名中是不能使用的，但是 path 可以，所以感觉还是中划线好点

驼峰式：遇到有人写错查的时候坑死你，大 I 小 L 就够把你压箱底儿的大刀抽出来了
下划线：下划线不能用在域名里面，你确定要时刻记着什么地方可以用什么地方不能用吗
横线：看着前面两条懒得说话

最近正好在设计这块，也是很纠结，综合结论就是：ai 推荐 a-b 这种命名，但是编辑器 a-b 复制会截取，所以使用 a_b ，但是，但是，微信回调必须是 xx.com/a/b 这种形式，最后项目就变成了这 3 种形式都有的组合

我喜欢中划线，好输入好看

下划线和驼峰都属于不好输入不好看

考虑被搜索引擎抓取，就用中划线-
否则就用下划线_
驼峰是下下策

呃，下划线

@lveye 标准来了，支持小驼峰

ai 时代用下划线中划线更好些？有利于 llm 分割 token

下划线看不清，中划线比驼峰好看

减号
大家以后也叫中划线为为减号吧

@sunny2580839896 如果只是编辑器不适应，编辑器配置一下对应的设置，让下划线能直接选中就好了。

全小写尽量一个词，一个词不行就简写

GET: api/shop/list
GET: api/shop/info
POST: api/shop/save

绝对是中划线，没别的选，甚至没有多想的必要，真的

如果是前端，URL 友好格式是用 dash （-）分割
如果是后端 api ，打开 github 看看 fetch 请求你就懂了

中划线看着都舒服很多了

肯定连词线啊。

从古至今，path 中是否带有连词线，对 seo 都没有影响。

下划线 方便复制

@kingterrors 好的，谢谢大佬

-_ 2 者混合使用
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/systemd-network-targets-and-services_configuring-and-managing-networking

优先考虑不加线
/api/getList --> /api/list

非加不可的话，个人倾向于 中划线
/api/get-list

切换大小写打字很烦

拒绝反人类的大小写，遇到近似字符简直抓狂，还有部分客户端可能会自动转换为全小写，最佳实践就是全小写。

公司里大部分都在用驼峰形式，但是这个东西有时候一个大小写没注意就 404 了，尤其当前端对自己眼睛比较自信，不复制而自己手打的时候
下划线没法申请域名，所以 URL 中其他地方我也都没用过下划线
自己平时定义 URL 用中划线比较多，个人域名也是两个字母中间一个中划线

驼峰好像对有些设备软件兼容不行，会有忽略大小写的情况。

我指的是 URL 中的驼峰

难道不应该是 GET /api/posts 吗？为什么还要多此一举/api/get-posts ？

Restful 应该不存在这个问题，都用 method 动词代替了。

/apis

get 是 http 方法。s 代表 list 。

我更喜欢 M$ 的 API 风格指南，该指南推荐中划线。我猜想这可能和 HTTP 协议的整体风格有关。

这取决于用 java 还是用 python 吧,java 大家都写驼峰,python 都是蛇

url 里不能有动词啊，应该是/api/list

restful ，不要 get ，就是/api/list 简单明了

seo 为王的年底啊，大家都把 seo 当 sb 伺候？

看了一下大家说的，我比较认可的是
前端页面路径使用中划线 如 https://github.com/settings/security-log
后端的接口使用下划线 如 api/get_list

用 next.js 怎么办. url 是目录自动生成的. 目录总要驼峰合适吧

@chendy vscode 中可以配置连字符，配完后双击也可选

感谢 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 命名中。

[_]