优先使用 的 media 属性实现 css 条件加载，浏览器根据媒体查询是否匹配决定是否下载并应用样式表，无需 js，现代浏览器（chrome 80+ 等）在不匹配时默认跳过下载。
怎么用 media 属性做 CSS 条件加载
HTML 里最轻量、最原生的条件加载就是靠 <link> 的 media 属性，浏览器会根据媒体查询是否匹配来决定是否下载和应用该 CSS。它不依赖 JS，也不触发重排，适合响应式场景下的按需加载。
常见错误是写成 media="screen and (min-width: 768px)" 却在桌面端首次加载时仍下载了移动端 CSS——其实只要媒体查询不匹配，现代浏览器（Chrome 80+、Firefox 69+、Safari 14+）默认就不会发起请求。
- 确保
media值是合法媒体查询，比如media="(prefers-color-scheme: dark)"或media="print" - 不要混用
rel="stylesheet"和rel="preload"：后者无视media，会强制预加载 - 调试时看 Network 面板，筛选
Initiator列为parser且状态码为200的请求，确认是否真被跳过
如何用 loading + data-src 实现图片条件加载
原生 loading="lazy" 只控制可视区懒加载，不是“条件”；真要按设备特性、网络类型或用户行为加载，得手动接管 src 设置。核心思路是：先占位，再判断，后赋值。
典型场景包括：移动设备只加载 WebP，桌面加载 AVIF；2G 网络下 fallback 到 JPEG；或用户滚动到某区域再加载高清图。
- 把真实地址存在
data-src或data-srcset，src设为空或低质量占位图 - 用
matchMedia()检测(width)、(prefers-reduced-motion)等，比 UA 字符串可靠得多 - 注意
picture元素的source[media]是渲染时条件匹配，但所有srcset中的资源仍可能被预加载（取决于浏览器策略），不能完全替代 JS 控制
import() 动态导入如何配合条件逻辑
JS 层面的条件加载，import() 是目前最标准的方式，支持按环境、路由、权限等动态加载模块，且返回 Promise，可链式处理。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
容易踩的坑是把它当成“if-else 加载”，却忽略了模块路径必须是静态字符串（不能是变量拼接），否则 webpack/vite 无法做代码分割。
- 路径必须字面量，例如
import("./utils/track.js")✅，import(`./${type}.js`)❌（会导致全量打包） - 可在
if或switch内部调用import()，只要路径确定，如：if (isMobile) import("./mobile-nav.js") - 服务端渲染（SSR）环境下，
import()不会执行，需配合typeof window !== "undefined"守卫
为什么不用 document.write() 或 eval() 加载脚本
这类方式看似能“条件执行”，但实际已严重过时，且带来安全与维护双重风险。现代浏览器对 document.write() 在 async 脚本后调用直接忽略；eval() 执行远程 JS 等同于 XSS 开门。
更关键的是，它们绕过了浏览器的加载队列、缓存策略和 CSP 限制，导致资源不可追踪、无法调试、难以审计。
- CSP（Content-Security-Policy）会拦截
eval()和内联脚本，除非加'unsafe-eval'，这等于放弃安全底线 -
document.write()在页面解析完成后调用会清空整个文档，不是“加载”，是“重置” - 真正需要运行时决策的，应走
fetch()+new Function()（仍不推荐）或更稳妥的import()+ 构建时分包
条件加载的本质是减少无效传输，不是掩盖加载逻辑。越想“灵活”地拼 URL 或 eval 字符串，越容易掉进兼容性、安全性和可维护性的坑里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
