打开一个只使用HTML5语义标签和Flexbox布局的个人页面，在最新版Chrome中一切正常，但把它发送到一台仍然运行IE11的电脑上，很可能会出现头部、导航、主体区域全部挤在一起，甚至JavaScript报错导致交互失效。兼容旧浏览器并不是把新特性全部删掉，而是通过标准模式、特性检测、降级样式和脚本转译，让页面在不同内核中都能提供可用的内容与基本体验。以下从结构、样式、脚本和测试四个层面拆解。
一、结构兼容：先让旧浏览器认识HTML5标签
很多旧版浏览器对HTML5新增的<header>、<nav>、<section>、<article>和<footer>等标签并不识别，会直接把它们当作未知行内元素处理，导致文档树和默认样式异常。解决这个问题的第一步是声明完整的DOCTYPE，让浏览器进入标准模式，而不是怪异模式。
接下来可以引入html5shiv，这个脚本会在IE9以下浏览器中创建对应的元素节点，使CSS能够正常匹配这些标签。在页面头部通过条件注释加载即可，现代浏览器会忽略这段内容。同时添加<meta http-equiv="X-UA-Compatible" content="IE=edge">，可以避免IE进入兼容视图导致渲染混乱。HTML结构本身也要尽量保持语义清晰，避免嵌套过多的表格结构，减少不同浏览器解析差异。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <!--[if lt IE 9]> <script src="https://oss.maxcdn.com/html5shiv/3.7.3/html5shiv.min.js"></script> <![endif]--> </head> <body> <header>个人主页</header> <nav>导航</nav> <section>内容区域</section> </body> </html>
对于<video>和<audio>等媒体标签，旧版浏览器无法原生播放，可以借助Flash或提示用户升级。更好的做法是提供链接或文字说明作为后备内容，让用户至少能获取信息。表单的新输入类型，如<input type="date">在旧版中会退化为普通文本框，业务逻辑需要先做类型判断。
二、样式兼容：从降级方案写到@supports增强
旧浏览器最常见的问题是Flexbox和Grid布局失效。一个稳妥的顺序是：先书写不依赖新特性的基础布局，例如使用float、inline-block或table-cell，确保页面在旧浏览器中也有基本可读的排列；再用@supports检测浏览器是否支持Flexbox或Grid，在支持时覆盖为更现代的布局。
/* 基础降级布局 */
.personal-card {
display: inline-block;
width: 48%;
vertical-align: top;
margin-right: 2%;
}
/* 支持Flexbox时升级 */
@supports (display: flex) {
.personal-card {
display: flex;
flex-direction: column;
margin-right: 0;
}
}
CSS前缀同样不能忽略。早期版本的Safari、Android浏览器以及IE都需要特定的前缀才能识别属性。可以使用Autoprefixer在构建阶段自动添加前缀，也可以手动为transition、transform、animation等补上-webkit-、-moz-、-ms-前缀。注意前缀只应作用于必要属性，滥用反而会增加维护成本。
对于CSS变量、calc()、position: sticky等特性，旧浏览器可能完全不支持。此时需要给出后备值。比如在声明width时先写固定像素值，再写calc()表达式，旧浏览器会忽略不认识的声明，保留前一个值。背景渐变、圆角等视觉增强在旧浏览器中即使降级为纯色或直角，一般也不会影响核心信息。
响应式方面，旧版移动浏览器可能无法正确识别<meta name="viewport">，但现代个人页面通常面向的旧浏览器主要是桌面端IE，移动端兼容更多依赖WebView。桌面页面如果使用固定宽度，可以减少缩放和重排问题。但不必为了兼容而完全放弃响应式，只需要在小屏断点中测试基础布局是否正常。
三、脚本兼容：ES5转换与polyfill补齐API
旧版浏览器对ES6及以上语法支持有限，箭头函数、let与const、模板字符串、解构赋值等会导致整个脚本解析失败。使用Babel等工具将代码转译为ES5，可以把语法差异消除到最低。Babel可以配合webpack、Rollup等构建工具，也可以单独使用命令行处理。转译后的代码可读性下降，但兼容性显著提升。
仅转换语法还不够，Promise、fetch、Object.assign、Array.prototype.includes等API在旧浏览器中根本不存在。需要在页面加载业务脚本之前引入对应的polyfill，或者使用core-js按需注入。一个常见的做法是根据特性检测按需加载，而不是一股脑把所有polyfill都塞给现代浏览器。
if (!('Promise' in window)) {
var promiseScript = document.createElement('script');
promiseScript.src = 'https://cdn.jsdelivr.net/npm/core-js-bundle@3.36.0/minified.js';
document.head.appendChild(promiseScript);
}
if (!('fetch' in window)) {
var fetchScript = document.createElement('script');
fetchScript.src = 'https://cdn.jsdelivr.net/npm/whatwg-fetch@3.6.2/dist/fetch.umd.js';
document.head.appendChild(fetchScript);
}
在处理DOM和事件时，也应优先使用标准API并做好兼容判断。例如addEventListener在IE9以上可用，旧版IE使用attachEvent。现代个人页面如果只需要支持到IE11，一般可以直接使用标准API，但必须避免使用NodeList.forEach等较新的方法，必要时先转换数组再遍历。事件对象、阻止默认行为等也建议封装统一的工具函数。
第三方库也会影响兼容范围。引入jQuery等库虽然能解决部分DOM操作差异，但会增大体积。对于个人页面这类轻量场景，更推荐原生JavaScript配合小型工具函数，降低依赖和兼容风险。如果必须使用框架，需要确认框架是否支持旧浏览器，否则构建产物中仍可能包含ES6语法。
四、测试验证：真实旧环境不可替代
开发者工具的模拟器只能近似还原旧浏览器行为，不能完全反映字体渲染、CSS引擎和脚本执行差异。比较可靠的方式是在虚拟机中安装Windows 7和IE11，或使用BrowserStack等服务进行真机测试。至少需要覆盖目标用户中占比最高的旧版本，不必追求支持所有浏览器。
测试时重点关注布局是否错位、交互是否可用、图片和字体是否正常加载。可以使用console日志和window.onerror捕获脚本错误，也可以借助Modernizr输出特性检测结果，快速定位哪些API缺失。根据测试反馈调整polyfill和降级样式，形成逐步兼容的闭环。
兼容旧浏览器需要明确支持范围。对个人页面而言，支持到IE11以及最近两年的主流浏览器已经足够，更早的IE8、IE9投入产出比不高。可以把兼容方案做成可配置的工程化流程，通过browserslist指定目标浏览器，让构建工具自动完成前缀和转译，减少手工处理成本。