HTML中img标签src的./相对路径与直接写文件名路径的区别

你测试的两个场景下两种写法表现完全一致，是因为这些场景刚好处于两种写法的解析逻辑重合的边界，当场景发生变化时，二者的差异会非常明显，核心区别体现在三个维度：

• 构建工具的资源识别逻辑差异
  所有主流前端构建工具（Webpack、Vite、Rollup等）的静态资源处理规则中：
  • 带./前缀的路径会被明确识别为项目本地的静态资源，打包时会自动完成文件哈希重命名、路径替换、体积压缩处理，保障上线后的资源路径可用。
  • 不带./前缀的纯文件名路径，会被判定为非本地依赖：构建工具不会扫描、处理这类引用，最终打包时会将路径原样保留，直接交由浏览器运行时解析——这也是很多开发者遇到“本地开发图片正常，打包上线就404”问题的核心原因。
• 路径歧义性差异
  带./前缀的写法是明确的相对路径标识，可以彻底避免路径解析歧义：
  • 如果页面中存在<base>标签定义全局路径基准，不带./的纯文件名在部分老版本浏览器中可能被误解析为根路径下的资源，而非当前文档所在目录的资源；带./的写法不会出现这类解析偏差。
  • 如果项目中存在和资源同名的npm依赖，不带./的写法可能被构建工具错误识别为从node_modules引入对应模块；带./的写法不存在这类歧义。
• 特殊场景的兼容性差异
  在非HTTP/HTTPS的特殊协议场景（比如file://、浏览器扩展内部协议）下，部分严格模式的浏览器会对没有相对路径标识的纯文件名做安全校验，无法判断该引用是用户主动编写的合法本地路径，还是被恶意注入的资源请求，此时不带./的引用可能被安全策略拦截，带./的引用可正常加载。

为什么测试时两种写法没有区别
你目前的两个测试场景恰好是两种写法解析结果完全重合的情况：

1. 直接拖拽HTML文件到浏览器打开时，使用file://协议访问，没有路由重写、没有构建工具拦截、没有安全策略干扰，纯文件名和./前缀的解析结果完全一致；
2. 使用VS Code Live Server打开时，默认静态服务将HTML文件放在服务根路径下，没有多层路由层级，也没有开启严格的构建资源扫描规则，两种写法的解析逻辑自然完全重合。

只要测试场景切换为多层路由的单页应用、经构建工具打包后的线上环境，两种写法的差异就会直接显现。

内容的提问来源于stack exchange，提问作者Ruben Kubalyan