图片资源包依赖路径约定、构建工具介入与运行时策略协同管理，而非简单打包；须用相对路径避免部署子路径404，禁用空格中文，构建工具需静态解析路径以实现哈希化与拷贝，缓存更新靠文件名哈希，/public仅放免构建资源。
直接结论：图片资源包不是“打包”出来的，而是靠路径约定 + 构建工具介入 + 运行时策略三者协同管理的。单独依赖某一种方式，迟早会遇到 404、缓存不更新、构建后路径错乱等问题。
为什么用相对路径而不是 /images/xxx.png？
绝对路径以 / 开头，浏览器永远从域名根目录找资源。一旦项目部署到子路径（比如 https://example.com/my-app/），所有 /images/logo.png 就会请求 https://example.com/images/logo.png，而非 https://example.com/my-app/images/logo.png，直接 404。
- 正确做法是统一用相对路径：
src="images/logo.png"或src="../assets/photo.jpg"，以当前 HTML 文件位置为基准解析 - 避免混用
./images/和images/——两者等价，但多打./增加出错概率，也无实际收益 - 路径中禁止空格和中文，否则 URL 编码后难调试，且部分 CDN 或代理服务会拒绝带编码的请求
Webpack/Vite 等构建工具怎么接管图片路径？
构建工具（如 Webpack 的 html-loader、Vite 的 import.meta.glob）能自动识别 HTML 中的 src、href，把相对路径转成哈希化后的产物路径，并拷贝资源到输出目录。但前提是路径必须可静态分析。
- 不能写
src="{{cdnUrl}}/logo.png"或src="${base}/icon.svg"—— 构建阶段无法解析变量，会报错或漏处理 - 第三方图床链接（如
https://cdn.example.com/xxx.jpg）可直接写死，无需构建介入，但要自己管缓存和可用性 - 若用
import方式引入图片（如import logo from './logo.png'），构建工具会返回带哈希的 URL，适合 JS 动态插入场景
如何让浏览器加载新图而不是旧缓存？
浏览器对图片默认强缓存，改了文件内容但没改 URL，用户就看不到更新。这不是前端代码问题，是 HTTP 缓存机制在起作用。
- 最稳妥方案：构建时给文件名加哈希，如
banner.a1b2c3d4.webp，URL 变了，缓存自然失效 - 开发期快速验证：手动加查询参数，如
src="photo.jpg?t=1727571600"，但上线禁用——CDN 和中间代理可能忽略?后参数 - 服务端配合：设置
Cache-Control: public, max-age=31536000（一年），但只对带哈希的静态文件生效；HTML 文件本身应设no-cache或短缓存
图片资源包里要不要建 /public 或 /static 目录？
不需要强制建。Vite、Zero Server、甚至 file:// 协议都支持同目录下直接访问 .png、.css。关键不是目录结构，而是“HTML 入口是否明确”以及“路径是否一致可推导”。
- 如果团队规范要求分离，
/public适合放不参与构建的资源（如favicon.ico、robots.txt） - 参与构建的图片（需压缩、转格式、加哈希），建议和组件代码放一起，例如
components/Header/logo.png，由构建工具统一处理 - 切忌在不同地方重复放同一张图——容易更新遗漏，也增加体积
真正容易被忽略的点是：路径解析逻辑和构建工具的静态分析能力必须对齐。写一个看似正确的 src，但因为用了模板字符串、变量拼接或运行时计算，构建工具就“看不见”这张图，也不会拷贝、不会哈希、不会压缩——它就只是个普通字符串，上线后大概率 404。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
