URL.createObjectURL仅适用于File或Blob对象，无法处理外部URL；它生成临时blob URL用于预览用户本地文件，使用后须调用revokeObjectURL释放内存，不适用于路径映射或外部资源加载。
URL.createObjectURL 不能解决外部资源路径映射
它根本不是为“外部资源”设计的——URL.createObjectURL 只接受 File 或 Blob 对象，无法处理 https://、http://、file:// 等真实 URL。试图传入字符串路径（如 "./assets/photo.jpg"）会直接抛出 TypeError: Failed to execute 'createObjectURL' on 'URL': Overload resolution failed。
常见误解是把它当成“路径转 URL 工具”，实际它是“内存对象 → 临时引用 URL”的桥接器。外部资源本就可直接用于 <img src> 或 fetch()，根本不需要也不支持用 createObjectURL 做二次包装。
什么时候你会误以为需要它来映射外部路径
典型场景其实是：你拿到的是一个相对路径或 CDN 地址，但页面部署后 404；或者你在本地开发时用 file:// 协议打开 HTML，图片加载失败。这些都不是 createObjectURL 能修的——它们属于路径配置、服务部署或协议限制问题。
- 静态资源 404：检查构建输出目录结构、
<base href>设置、Webpack/Vite 的public目录约定 -
file://下加载失败：浏览器默认禁用跨文件读取，必须起本地服务器（如npx serve） - CORS 阻止图片显示：外部域名未设置
Access-Control-Allow-Origin，createObjectURL完全不参与这个链路
真正该用 createObjectURL 的地方：用户选中的本地文件
只有当数据来自用户主动选择（<input type="file">）、拖放（event.dataTransfer.files）或前端生成（new Blob()）时，才轮到 createObjectURL 出场。它把不可寻址的二进制块变成 DOM 可消费的地址。
立即学习“前端免费学习笔记（深入）”；
例如预览用户上传的图片：
const input = document.querySelector('input[type="file"]');<br>input.addEventListener('change', e => {<br> const file = e.target.files[0];<br> if (file && file.type.startsWith('image/')) {<br> const url = URL.createObjectURL(file);<br> document.querySelector('#preview').src = url;<br> // 记得 later: URL.revokeObjectURL(url)<br> }<br>});
注意三点：
-
file必须是File实例，不是字符串路径 - 生成的
url形如blob:http://localhost:3000/xxx，仅当前页面有效 - 一旦不再需要（比如换图、页面卸载），必须调用
URL.revokeObjectURL(url)，否则内存不会释放
想“映射”外部资源？换思路，别硬套 createObjectURL
如果你的目标是统一管理资源路径（比如从配置里读 URL、切换测试/生产环境 CDN），正确做法是：
- 用 JS 变量或配置对象存基础路径：
const CDN_BASE = 'https://cdn.example.com/v1/' - 拼接时确保斜杠一致性：
${CDN_BASE}images/${id}.jpg - 对动态生成的外部链接做存在性校验（如
fetch(url).then(...)），而不是幻想createObjectURL能兜底 - 需要离线缓存？走
Cache API或 Service Worker，不是靠对象 URL
对象 URL 的生命周期绑定在 document 上，页面刷新即失效，它不保存、不跨页、不持久——这些特性决定了它只适合临时、一次性、内存内的资源绑定。拿它去“映射外部路径”，就像拿胶带去修高压线，方向错了，越用力越危险。
