404问题根源在于请求URL与服务器实际路径映射不一致；应通过开发者工具Network面板查看真实Request URL，比对HTML所写路径、浏览器解析路径及服务器文件物理路径三层是否对齐。
绝对路径写对了，但还是 404，问题大概率不在“路径本身”，而在它被解析时的上下文或服务器实际部署结构。直接改 href 或 src 的值往往无效，得先确认浏览器真正发出了什么请求。
怎么看浏览器到底请求了哪个 URL
别猜，打开开发者工具（F12）→ 切到 Network 标签页 → 刷新页面 → 找红色的 404 请求 → 点开看 Request URL。这个地址就是真实发出的请求，和你写的 href="/css/style.css" 是否一致，一眼就能判断。
- 如果
Request URL是https://example.com/css/style.css，但你服务器上实际文件在/assets/css/style.css，那就是路径映射错位 - 如果
Request URL是https://example.com/static/js/app.js，而你用 Nginx 反代后端，但没配location ^~ /static/规则，就会直接 404 - 如果
Request URL带了端口（如:8080）或子路径（如/admin/css/style.css），说明<base href="...">被设过，且值和当前部署路径不匹配
为什么 /xxx 这种根路径容易出错
以 / 开头的路径，基准永远是域名根（https://example.com/），不是你本地文件夹结构，也不是开发服务器默认的 /public 目录。构建工具（Vite、Vue CLI）输出的路径、Nginx 的 root 设置、CDN 的缓存路径，三者必须对齐。
- Vite 中
base: "/myapp/"，HTML 就必须有<base href="/myapp/">，否则所有/xxx都会少一层前缀 - Nginx 的
root /var/www/myapp;意味着/css/style.css对应磁盘路径/var/www/myapp/css/style.css，不是/var/www/css/ - 静态托管服务（如 Netlify）通常把
dist/整个目录当根，所以/css/必须真实存在于dist/css/下
Nginx 反代时 /xxx 404 的典型修复方式
后端返回的 HTML 里写了 href="/static/js/app.js"，但 Nginx 主 location / 只代理 API，没管静态资源路径，浏览器就直接向你的域名发请求，结果 404。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 最稳方案：补全静态路径的
location块，例如location ^~ /static/ { proxy_pass http://backend/; }—— 注意proxy_pass末尾的/，它会剥离/static/前缀再转发 - 次选方案：用
sub_filter在响应 HTML 时把href="/static/替成href="/assets/，再单独配location ^~ /assets/；但需开启sub_filter_types text/html;且不适用于 HTTPS 后端 - 避免方案：让后端返回相对路径（
href="static/js/app.js"）或带<base>的绝对路径（<base href="https://cdn.example.com/">），从源头解耦
本地双击打开 HTML 文件时 /xxx 一定失效
file:// 协议下，浏览器把 /xxx 解析成系统根目录（如 C:/xxx），而不是项目根。这不是 bug，是协议行为。
- 绝对不要双击运行 —— 改用
python3 -m http.server 8000、npx serve -s dist或 VS Code Live Server 插件 - 如果必须双击测试，把所有
/xxx改成相对路径（./xxx或xxx），但上线前还得改回来，徒增风险 - 构建工具的
public目录内容会被原样复制到输出目录根，所以public/css/style.css→ 输出后是/css/style.css，前提是部署时整个输出目录被当根目录用
真正卡住人的从来不是“怎么写路径”，而是“路径在哪个环节被谁按什么规则重写了”。每次 404，先看 Request URL，再核对三层路径：HTML 里写的、浏览器算出来的、服务器上真实存在的。
