unpkg根据package.json的unpkg、main、module字段及文件名优先级自动定位JS文件；支持?module参数返回ESM格式并重写裸导入；加载失败常因字段缺失、CORS、CJS/ESM混用或恶意包风险，生产环境须锁定版本并校验完整性。
直接用包名就能加载，但得知道它默认找哪个文件、怎么控制版本、以及为什么有时候 script 标签会报错或空白——这些不是 CDN 的问题，而是 npm 包自身发布结构和浏览器加载机制共同决定的。
unpkg 如何根据包名自动定位到 JS 文件
当你访问 https://unpkg.com/lodash，unpkg 不是随便挑一个文件返回，而是按固定优先级查 package.json 字段：
- 先看
unpkg字段（专为 unpkg 设计，最高优先级） - 没有就看
main字段（CommonJS 入口） - 再没有就 fallback 到
module字段（ESM 入口） - 最后尝试找
index.js或同名.mjs文件
比如 https://unpkg.com/react 会跳转到 react.development.js，因为它的 package.json 里 unpkg 字段明确指向这个 UMD 构建产物；而 https://unpkg.com/zustand 会返回 index.mjs，因为它没设 unpkg，但有 module 字段。
用 &module 参数启用原生 ESM 加载
普通 <script src="..."> 是 classic 模式，不支持 import。想在浏览器里写 import { create } from 'zustand'，必须用 type="module" + ?module：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<script type="module" src="https://unpkg.com/zustand@4.5.0?module"></script>-
?module会让 unpkg 返回 ESM 格式入口（通常是module字段指向的文件），且自动重写内部裸模块导入（如import { nanoid } from 'nanoid'）为对应 unpkg URL - 注意：所有依赖也得支持 ESM，否则运行时报
Failed to resolve module specifier
常见加载失败原因和绕过方式
不是所有包都能“直接用”，失败往往卡在这几个点：
-
404：包没发布main/unpkg字段，或只发了types或src目录（比如某些 TS 库没配构建产物） -
CORS 错误：包内引用了非同源资源（如图片、字体），但 unpkg 不代理跨域请求；此时需改用本地托管或自建镜像 -
ReferenceError: require is not defined：加载了 CJS 格式文件（如lodash/index.js），但放在type="module"下执行 - 空白无反应：包本身是纯 ESM 且无默认导出，或依赖未被
?module重写（比如用了import.meta.url动态路径）
快速验证是否可直接用：打开 https://unpkg.com/browse/包名@版本/，看有没有 .js 或 .mjs 文件，且不是空目录或 src/。
安全与稳定性提醒
unpkg 是公开 CDN，内容完全来自 npm registry，不做过滤或审计。2025 年已有多个恶意包通过拼写劫持（如 react-dom-18）被上传，并借 unpkg 快速分发钓鱼页面。生产环境务必：
- 锁定具体版本（
@1.2.3），禁用@latest或@next - 避免引入未审核的第三方 UI 组件或工具库（尤其含
eval、innerHTML或远程脚本加载逻辑的） - 关键项目建议搭配 CSP 策略：
script-src 'self' https://unpkg.com，并用integrity属性校验哈希（需手动从 unpkg 响应头提取Content-Security-Policy: ...中的sha256-xxx）
最不可靠的假设，就是认为“能加载成功 = 可以放心用”。
