条件加载CSS，Modernizr检测浏览器功能

本文深入解析了Modernizr在现代前端开发中的正确使用方法与常见误区，强调它并非自动注入HTML类名的“魔法工具”，而是需要严格把控加载时机、检测项配置和脚本执行顺序的功能探测库；同时澄清了Modernizr.load已废弃的事实，推荐用loadjs或原生import()替代，并指出@supports更适合纯CSS能力检测，而Modernizr真正的价值在于为JS行为分支（如按需初始化插件或加载polyfill）提供可靠依据——帮你避开构建遗漏、类名失效、兼容性误判等高频坑点，真正实现精准、轻量、可维护的渐进增强。

Modernizr 检测失败，html 上没加类名？

Modernizr 不会自动往 html 元素写类名，除非你手动调用 Modernizr.addTest 或等它初始化完成。更常见的是：脚本加载顺序错了，或者 DOM 尚未就绪就执行了依赖类名的 CSS/JS。

• 确保 modernizr.js 在所有依赖它的 CSS 和 JS 之前加载（最好放在 底部，但早于 ）
• 别在 DOMContentLoaded 之前读取 document.documentElement.className —— 类名是同步注入的，但得等脚本执行完
• 检查控制台有没有 Uncaught ReferenceError: Modernizr is not defined，说明路径错或加载失败

CSS 中用 .no-flexbox 却不生效？

Modernizr 插入的类名默认是 flexbox（支持）和 no-flexbox（不支持），但前提是检测项被启用。如果你用的是自定义构建版，很可能把 flexbox 检测去掉了。

• 访问 Modernizr 官网下载页，勾选 flexbox 再生成，别直接用“推荐版”
• 在浏览器控制台运行 Modernizr.flexbox，返回 true/false 才算检测成功；返回 undefined 就是没包含该测试
• .no-flexbox 是兜底用的，但别只靠它写降级样式 —— 有些老浏览器连 @supports 都不支持，得配合 JS 切换 class

想按需加载 polyfill，但 Modernizr.load 报错？

Modernizr.load 在 Modernizr 3.0+ 已被移除，官方明确不维护了。你现在看到的报错基本都是用了旧文档或过时教程。

• 现代方案是用 loadjs 或原生 import() 配合 Modernizr 判断，例如：

  if (!Modernizr.fetch) { loadjs('polyfill-fetch.js'); }

• 别再搜 “Modernizr.load 教程”，那些全是针对 2.x 的，兼容性差且有 CSP 风险
• 如果必须动态加载资源，优先走 document.createElement('script') + onload，比任何封装都可控

用 @supports 还要 Modernizr？

不需要。CSS @supports (display: flex) 是原生能力检测，比 Modernizr 更轻、更准，而且无需 JS。Modernizr 主要解决两类问题：@supports 不支持的浏览器（IE），以及需要 JS 介入的逻辑分支（比如要不要初始化某个插件）。

• 纯样式降级 → 用 @supports，干净利落
• 需要 JS 行为分支（如“有 IntersectionObserver 才启动懒加载”）→ 用 Modernizr.intersectionobserver 或直接 'IntersectionObserver' in window
• 别为了“统一风格”硬套 Modernizr，多一次 JS 执行、多一个 HTTP 请求、多一层缓存失效风险

实际项目里最常漏掉的，是构建时没确认 Modernizr 版本和检测项是否匹配，以及把 no-js 类名当万能开关 —— 它只在 JS 失效时起作用，跟功能检测不是一回事。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《条件加载CSS，Modernizr检测浏览器功能》文章吧，也可关注golang学习网公众号了解相关技术文章。