浏览器将href="/css/style.css"在file://协议下解析为磁盘根目录（如file:///css/style.css），而非项目文件夹，导致404；根本原因是/在本地双击时指向d:/等物理根，缺少站点上下文。
href="/css/style.css" 在双击打开时 404 的真实原因
浏览器看到 /css/style.css，会按「站点根目录」解析，即认为资源在 http://localhost/css/style.css 或 https://example.com/css/style.css 下。但双击打开的地址是 file:///D:/project/index.html，此时 / 指向的是磁盘根（D:/），不是你的项目文件夹。所以它实际请求的是 file:///css/style.css，自然 404。
这不是路径写错了，是你默认的「根」根本不存在——/ 在 file:// 协议下没有站点上下文，它只认物理磁盘根。
- 开发阶段别双击打开 HTML 文件，改用
python3 -m http.server或 VS Code Live Server - 所有以
/开头的href、src在本地双击场景下一律失效，不是 bug，是协议限制 - 构建工具（如 Vite）里
/assets/main.js能用，是因为它在启动 dev server 后才生效，且构建过程会重写路径
相对路径中 ../ 和 ./ 到底怎么算
../ 不是“返回上一级”，而是「解析时向上跳一层目录」；./ 也不是必须写，只是显式声明「从当前目录开始」。关键看 index.html 的**真实位置**，不是你想象的“它应该在哪”。
比如 index.html 实际在 /pages/home/index.html，想链接同级的 /pages/about.html，就得写 href="../about.html" —— 因为当前文件在 home/ 子目录下，向上跳一层才是 pages/ 目录。
-
href="images/logo.png"和href="./images/logo.png"在 HTML 中完全等价，./纯属冗余 - 嵌套超过 4 层（比如
../../../..）时，路径难读、一挪就断，优先考虑重构目录结构 - CLI 工具或 Node.js 脚本里
./有实际作用（防模块解析歧义），但 HTML 中它不改变行为
什么时候非得用带 https:// 的绝对 URL
只有两类情况真正需要完整协议+域名的绝对路径：
- 引用外部网站或 CDN 资源，例如：
href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a" - 生成要发到微信、钉钉、邮件里的 HTML：这些环境不走本地服务器，也不认
/根，只能靠完整 URL 确保可访问
href="D:\project\contact.html" 是本地文件绝对路径，现代浏览器一律屏蔽，连 IE 都早不支持了，属于无效写法。
Vite/Webpack 构建后，/ 开头路径还能直接用吗
能，但逻辑变了——构建工具会接管路径解析。比如你在源码里写 href="/assets/main.js"，Vite 默认会把它重写为带 hash 的输出路径（如 /assets/main.abc123.js），或自动补上 base 配置前缀（如 /my-app/assets/main.js）。
这意味着：你写的 / 不再是浏览器原生解析的站点根，而是构建工具定义的「输出根」。
- 务必查文档确认是否启用了
base配置（Vite 的base、Webpack 的publicPath） - 如果部署到子路径（如
https://example.com/my-app/），不配base就会导致所有/assets/xxx请求 404 - 构建产物中的
index.html里出现的/路径，已经不是你手写的原始字符串，而是被处理过的
最易忽略的一点：路径问题从来不是“写对了就行”，而是取决于「谁在解析它」——是浏览器？本地文件协议？dev server？还是构建后的静态资源服务？搞错上下文，再标准的写法也会失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
