HTML 本身不支持 {id} 占位符，它仅是路由框架或 API 文档的约定；真实链接需通过 JS 拼接（如 /user/${userId}）或服务端渲染生成，否则会触发 URL 编码错误或 404。
HTML 路径中 {id} 是占位符，不是 HTML 语法本身支持的参数机制
浏览器解析 HTML 时完全不识别 {id} 这种写法——它既不是 HTML 标准属性，也不是 URL 规范的一部分。你看到的 {id} 几乎都来自后端路由框架（如 Express、Next.js、Vue Router）或 API 文档约定，HTML 自己没能力标注“必填”或“可选”。
常见错误现象：
• 直接在 <a href="/user/{id}"> 中写 {id}，点击后跳转到字面路径 /user/%7Bid%7D（URL 编码后的花括号）
• 误以为加个 required 属性就能校验，但 <a required> 在 HTML 中无效
- 真实使用场景：这类写法只出现在文档、模板字符串、路由配置里，比如 Vue Router 的
path: '/user/:id'或 OpenAPI 的/users/{id} - 如果是在前端拼接链接，必须用 JS 替换占位符：
`/user/${userId}`或"/user/" + userId - 服务端渲染时（如 Next.js），
{id}实际对应文件系统路径app/user/[id]/page.tsx，此时“必填性”由框架路由匹配逻辑决定，而非 HTML 标签
想让路径参数“必填”，得靠 JavaScript 运行时控制或服务端拦截
HTML 标签本身没有参数校验能力，所谓“必填”，本质是业务逻辑约束：用户没提供 id 时，不该生成或跳转到那个链接。
- 前端常见做法：用条件渲染隐藏链接，比如
{userId && <a href={`/user/${userId}`}>详情</a>} - 如果用表单提交到带参数的路径，需在
submit事件中校验：if (!id) return alert("ID 不可为空") - 服务端更可靠：Nginx 或后端路由可返回 404 或 302，例如 Express 中
app.get('/user/:id', (req, res) => { if (!req.params.id) return res.status(400).send("id 必填") }) - 注意兼容性：不要依赖
:required这类伪类选择器去控制<a>标签，CSS 里没有这个东西
OpenAPI / Swagger 文档里的 {id} 和 HTML 没关系，别混淆
你在接口文档里看到的 GET /api/users/{id}，只是 OpenAPI 规范对路径参数的描述语法，和 HTML 渲染、表单提交、超链接生成全无关联。
立即学习“前端免费学习笔记（深入）”；
- 这种写法不会自动变成可点击链接；要生成真实链接，仍需手动替换或用 SDK
- 有些文档工具（如 Swagger UI）会提供“Try it out”按钮，背后是 JS 动态拼接 URL 并发请求，不是 HTML 解析了
{id} - 错误认知：“我在 HTML 里照抄 OpenAPI 的路径就能跑通”——结果往往是 404，因为没替换占位符，也没传实际值
真正该检查的地方：URL 构造过程，而不是 HTML 标签本身
最容易被忽略的是路径拼接时机。很多 bug 来自把未定义变量直接塞进 URL，比如 href="/post/{id}" 看似写了占位符，实则连 JS 都没介入，纯静态 HTML 就是错的。
- 检查所有含动态路径的
href、src、fetch()地址，确认是否经过变量插值 - 浏览器开发者工具 Network 标签页里看发出的真实请求路径，比看源码更准——源码里写的
{id}很可能根本没被替换 - 如果用构建工具（Vite、Webpack），注意
import.meta.env或process.env注入的路径前缀是否覆盖了你的动态段
