必须对href中动态拼接的文件名、查询值等路径片段用encodeURIComponent编码，不可整URL编码或使用encodeURI；空格、中文、&等未编码会导致截断或404。
href里有中文、空格或&，点击就404？
浏览器把 href 当 URL 解析，遇到未编码的特殊字符会直接截断或误解析。比如 href="文档.pdf" 实际请求的是 文档，后面被丢弃；href="page?name=张三&age=25" 里的 & 被当成查询参数分隔符，导致参数错乱。
必须用 encodeURIComponent() 处理动态拼接的部分，不是整个 href 字符串——只对文件名、查询值这类「路径片段」编码：
-
href="/files/${encodeURIComponent(filename)}"—— filename 是变量，如"报告 v2.pdf" -
href=`/search?q=${encodeURIComponent(query)}`—— query 含空格、中文、&都得包一层 - 路径分隔符
/不能被encodeURIComponent()编码，否则变成%2F，服务器找不到路由 - 别用
encodeURI()替代，它不编码/和?，但会漏掉&或=，反而更危险
href指向锚点时ID含中文或符号，跳转失败
锚点跳转靠的是 href="#xxx" 匹配目标元素的 id="xxx"，而 ID 值本身不能含空格、句点、冒号等，也不能以数字开头。浏览器对 ID 的合法性校验比你想象中严格。
如果后端或 CMS 允许用户输入标题生成 ID（比如把“我的第一篇笔记”转成 id="我的第一篇笔记"），这个 ID 在多数浏览器里根本无法被 # 定位到。
立即学习“前端免费学习笔记（深入）”；
- 生成 ID 时先用
encodeURIComponent()编码，再替换掉%和非法字符：比如"我的第一篇笔记"→"wo-de-di-yi-pian-bi-ji" - 前端运行时不要依赖
document.getElementById(decodeURIComponent(hash.slice(1)))，ID 不合法时查不到节点 - 现代框架（React/Vue）里用
useId()或ref管理锚点更可靠，绕过 ID 字符限制
mailto: 或 tel: 链接里带特殊字符怎么处理
mailto: 和 tel: 是协议链接，不走 HTTP 请求，但它们的参数部分仍需符合 URI 规范。比如邮箱地址本身不含特殊字符，但 subject 和 body 里可能有中文、换行、引号。
mailto:admin@example.com?subject=${encodeURIComponent("反馈：页面加载慢")}&body=${encodeURIComponent("请检查 CDN")}- 注意：
encodeURIComponent()会把换行符转成%0A，多数邮件客户端能正确还原，但某些旧版 Outlook 可能显示为文字%0A -
tel:+86-${encodeURIComponent(phone)}没意义——电话号码只能是数字、+、-、()、空格，不该出现需要编码的字符；若原始号码含中文括号或全角符号，先清洗再拼接 - 服务端生成这类链接时，确保已做
encodeURIComponent，前端不要再套一次，否则双重编码（如%变成%25）
CDN 资源路径含中文，相对路径 vs 绝对 URL 怎么选
本地开发时用相对路径最省事，但一旦静态资源托管到 CDN，路径逻辑就变了。比如 href="../assets/图标.svg" 在 HTML 文件移动后立刻失效；而写死 https://cdn.example.com/v1/icons/图标.svg 又让本地调试跑不通。
真正关键不是“编码”，而是“路径上下文是否稳定”：
- 构建时用环境变量注入 CDN 域名：
href="${CDN_BASE_URL}/icons/${encodeURIComponent(iconName)}" - 避免在 JS 中拼接 href 后直接赋值给
link.href或a.href，先验证字符串是否含未编码的空格或中文 - 上线前用 curl 测试生成的 href 是否返回 200，尤其关注含中文的路径段是否被 Nginx/Apache 自动解码两次
- 最隐蔽的坑：某些 CDN（如 Cloudflare）默认开启“自动重写 URL”，会把
%E4%BC%98这类编码强制转成 UTF-8 字节再匹配文件系统——而你的文件名其实是优.svg，不是%E4%BC%98.svg
