写这篇博客的起因挺简单：我前阵子接手一个 PC 端电商活动页的改版，发现团队里几个前端对"CSS 初始化"这件事的理解完全不一样——有人直接拷了一份老项目里的 reset.css，有人用 normalize.css，还有人干脆什么都不管，靠浏览器默认样式硬写。结果就是同一个页面在不同浏览器里对不齐，光修间距就花了两天。

后来我把京东、天猫、王者荣耀 PC 端这几个站的前端样式挨个扒了一遍，专门研究它们各自的 CSS 初始化源码，才发现这三个站虽然面向的用户群体完全不同、页面形态也差得很远，但在"初始化"这一步上既有大量共性，又藏着好几处值得玩味的产品级差异。这篇就把我拆解的结论整理出来，顺便聊聊哪些可以直接抄，哪些抄了反而会踩坑。

需要先说明一点：下面讨论的初始化规则，是我基于这几个站点的实际页面表现、公开的静态资源命名规律以及主流实现方案反推归纳的总结，不是把哪个站的原始源码逐行贴出来。但所有结论都经得起"打开开发者工具自己验证"的检验，你照着思路去页面上查，能对得上。

1. 初始化到底在解决什么问题：三个让前端头疼的默认样式

先别急着抄代码。如果你不理解初始化解决的是什么，抄来的 reset 只会变成项目里的僵尸代码。所谓 CSS 初始化，核心就两件事：消除浏览器默认样式差异、建立一套可控的基线样式。

1.1 同一段 HTML，三个浏览器三种长相

浏览器自带的 UA 样式（User Agent Stylesheet）并不统一。一个没有任何 CSS 的裸<p>标签，在 Chrome 里上下 margin 是 16px，在旧版 Firefox 里可能是 16px 但计算方式不同；<ul>的 padding-left 在 Chrome 里有 40px，在 IE 里又是另一套；<h1>的 font-size 在各浏览器里更是从 2em 到 1.92em 都有，堪称为数不多的"多个浏览器无法自动对齐"的历史遗留问题。

这就意味着，如果你不主动清零，你写的margin: 0实际上是叠加在浏览器默认 margin 之上的。你看到的间距是"默认值加你的值"，而不是你单方面定义的值。页面越复杂，这种不可控叠加就越致命。

注意：这里的"默认值"不是同一个值在不同浏览器里表现相同的意思。UA 样式本身在不同浏览器里就是不同的，比如<button>的字体继承策略，Chrome 里按钮默认不继承 body 的 font-family，而 Firefox 里则继承。这种差异靠写业务 CSS 一个一个补，成本太高。

1.2 从"清零"到"统一基线"的演进

早年间前端圈流行的是彻底清零式的 reset，最典型的就是那句被无数人复制粘贴的：

* { margin: 0; padding: 0; }

这种做法思路很纯粹：把所有元素的默认 margin 和 padding 全部干掉，让一切从零开始。但它的问题也明显——*选择器命中所有元素，包括::before和::after伪元素，大页面里性能开销不小；而且它把p、h1、ul这些本该有语义间距的标签也一并清零，后期你还得自己把间距加回来，等于"先删光再重写"。

所以后来更多团队转向"保留有用的默认样式、只修不一致的差异"的路线，俗称 normalize 方案。京东、天猫这类有大流量、多浏览器兼容压力的站点，实际采用的初始化方案更接近两者的结合体——既做整体清零，又对关键标签做精细化的基线定义。我在它们页面上看到的现象是：*通配清零仍然存在，但已经不再只写margin:0; padding:0两行，而是会带上box-sizing，这种写法从源头解决了早年 IE 盒模型和标准盒模型的差异。

1.3 初始化文件里的隐藏信息：站点对浏览器环境的妥协程度

一个很容易被忽略的细节是：初始化代码里写着哪些 hack、写着哪些-webkit-前缀，基本能反映这个站还要不要兼容老浏览器。京东、天猫作为面向全量用户的电商平台，注册用户里永远有一批老 IE、老旧国产浏览器，所以它们 2022 年之前的初始化代码里仍然保留着针对 IE7/IE8 的兼容写法，比如display: inline-block的 zoom hack、*html这类仅 IE 识别的选择器，后来随着 IE 退场才慢慢清掉。而王者荣耀 PC 官网这种偏品牌展示、面向游戏玩家的站点，浏览器环境明显更“新”，它的初始化就更干净，没有大量历史兼容包袱。

这一条我单独拎出来说，是因为很多人抄初始化代码时容易盲目照搬老项目的 reset，连里面的_zoom: 1、*+html这类古董 hack 一起抄进新项目。抄完代码既能跑，也不会报错，但文件里多了一堆没有任何作用的死代码，文件体积浪费了，还容易误导后来接手的人以为项目还在兼容某个老浏览器。

2. 三家都不约而同写死的基础规则：从标签到属性的一整套默认值

接下来进入正题。我按"初始化文件里最常见的声明"逐条拆，这些规则在三个站里基本都能找到，只是具体写法和优先级略有差别。

2.1 通配符清零的通病：为什么*还在用，但写法变聪明了

三个站的初始化文件里都能看到*通配符，但它们的写法已经从最早的*{margin:0;padding:0}演进得更细。以我在京东、天猫页面观测到的实际效果为例，它们的 UA 样式修正里基本长这样：

* { margin: 0; padding: 0; } *, *::before, *::after { box-sizing: border-box; }

第一段管的是"间距清零"，第二段管的是"盒模型统一"。把box-sizing: border-box加到所有元素上，意味着你写width: 100px时，最终渲染的宽度就包含 padding 和 border，不会出现"设了 100px 宽度，再加 10px 内边距，实际占 120px"这种一不留神就撑破布局的经典问题。

关于*的性能问题我要多说一句。在很多技术文章里*选择器被批评得厉害，说它渲染慢。实际上现代浏览器的样式匹配已经足够快，*在通常的页面规模下对性能的影响微乎其微。真正的问题不在性能，而在于*会把p、h1、ul这些语义化标签的默认间距也一并清零，导致你后边写文章类内容时，每个标题、每个段落都要重新定义 margin。京东、天猫这种电商页面本身就没什么长文排版场景，所以*清零的副作用不大，它们用得很果断。而像王者荣耀这种页面里有大量文案展示的站点，如果也完全用*清零，文案排版时就得重新补一遍间距，所以它不会对某些文字标签做粗暴清零，而是单独用"类 reset"的方式只处理盒子模型。

2.2 body 级别的初始化：字体、背景、行高的一次性约定

翻开三个站的初始化文件，body 这一层是投入笔墨最多的。基本的形态是这样的：

body { font-family: "Microsoft YaHei", "PingFang SC", "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 12px; line-height: 1.5; color: #333; background-color: #fff; }

这里面有几个细节值得展开：

• font-family的字体栈顺序不是随便排的。微软雅黑在前是因为 Windows 用户基数最大；苹方（PingFang SC）紧跟其后是适配 macOS/iOS；再往后是 Helvetica Neue 和 Arial 作为无衬线兜底。这个顺序把"当前系统最合适的字体"放在最前面，避免不同平台渲染出完全不同的字形外观。
• font-size: 12px是电商系的老传统。12px 是中文小字号的可读底线，字再小用户就看不清了，而且电商页面追求信息密度，正文用 12px 能塞下更多内容。王者荣耀官网的默认字号通常在 14px 上下，因为它不是信息流电商页面，不需要把字号压到极限。
• line-height: 1.5是一个相对值，能跟随 font-size 变化自动缩放，比写死line-height: 18px科学得多。你如果用了这个初始化，后边任何元素只要不单独覆盖 line-height，都会继承到 1.5 的相对行高，排版不容易出现文字截断。

天猫的 body 初始化里还会额外加一条-webkit-font-smoothing: antialiased，作用是让 Mac 下的字体渲染更细更平滑。这个属性在 Windows 上无效，但加上不影响任何东西，属于"为了部分用户而写的无害优化"。京东早期版本的 body 初始化里还出现过overflow-x: hidden，用来防止横向滚动条——这种做法副作用不小，它会把页面里超出视口的元素直接裁掉，调试定位问题时很难注意到。所以后来新项目里基本都不这么写了，改用html, body { max-width: 100%; overflow-x: hidden; }这种更温和的方案。

2.3 链接、列表、标题、表单控件：高频标签的细节微调

除了 body，初始化文件还会针对几个高频标签单独做处理，这也是三个站共性最强的部分。我用表格把这部分整理一下：

这里面我想重点展开img的vertical-align: middle。很多人不理解为什么 img 下边总有一条 3px 左右的空白缝隙，其实是因为图片默认是基线对齐（baseline），基线和底线之间的空隙就变成了图片下方的留白。设成vertical-align: middle之后，图片的对齐方式和文字中线对齐，空隙就没有了。三个站的初始化里对图片的处理还延伸到a img这个组合，也就是把链接里包的图片的边框也去掉——这个在 IE 时代非常重要，因为 IE 会给链接图片描一圈蓝色边框，现在虽然没这个问题了，但规范仍在。

至于button和input的字体继承，这个细节最容易被忽略但也最容易出问题。在没有初始化的情况下，Chrome 的按钮字体不会继承 body 的 font-family，你会在页面上看到按钮里的文字和别的文字字体不同。初始化里加上font-family: inherit之后，按钮字体就跟随 body 了，视觉上统一得多。

3. 差异点背后是产品形态的映射：京东、天猫、王者荣耀的初始化各自侧重什么

共性看完了，接下来看差异。这三个站放在一起对比特别有意思，因为它们的初始化差异恰恰反映了三类产品的不同诉求。

3.1 京东系：以容器和间距为主的重排版约定

京东 PC 端页面的初始化有一个非常典型的特征：对容器类元素做了大量默认约定。我观测到它的布局基线上普遍存在这类规则：

div { /* 继承自 reset 的默认块级特性，但额外约定 */ } .clearfix::after { content: ""; display: table; clear: both; }

这里有两层信息：

• 京东的页面结构是典型的"通栏大容器 + 栅格化模块"，初始化层面不需要花太多精力在文字排版上，更多是确保各种容器在默认情况下不出错。
• clearfix是浮动时代的产物。早年用float布局大行其道，父容器如果不主动清除浮动，子元素浮起来之后父容器高度会塌成 0，后面的兄弟元素会被顶上去。京东的初始化文件里直接内置了.clearfix工具类，要清浮动的时候套一个类名即可。

它还对dt、dd这类定义列表标签做了样式处理，让它们的 margin 和 padding 归零。小标签的初始化容易被忽略，但京东把这类商业页面里爱用的定义列表结构（比如一行标签带一段说明）的默认表现统一好了，写业务样式时就不用纠结 dl 默认的 margin 会不会干扰布局。这个处理方式值得借鉴：初始化时把你们项目中高频使用的"非主流标签"也一起处理掉。

3.2 天猫系：盒模型和媒体元素优先的精密控制

天猫 PC 端的初始化给我的感受是"更精细"。它的 reset 基础上明显加入了对box-sizing的强化约定，并且对媒体查询断点做了前置铺垫。核心风格可以归纳为：

html { /* 将根字体大小交给 JS 动态调整时使用 rem 布局 */ font-size: 100px; } body { font-size: 14px; }

这个写法非常电商。html的 font-size 设成 100px，配合 rem 单位做响应式布局时，1rem 就等于 100px，心算尺寸特别方便。同时 body 恢复成 14px 的常规字号，保证页面正文可读性。老版本天猫站在部分区域用 rem 做适配，靠的就是这样一套根字体约定。现在虽然更多转向了 vw/vh 方案，但初始化里保留一个绝对值的根字体仍然是有意义的——它让 rem 作为可选方案随时能用，不用临时改配置文件。

天猫初始化对媒体元素还有一个独特偏好：它为img、video、embed、object这类媒体标签统一设置了max-width: 100%，防止媒体元素在容器变窄时横向溢出。这在电商系统的商品详情页里特别重要，因为运营上传的图片尺寸不可控，如果图片比容器宽，没有max-width: 100%就会撑破布局。而京东的选择是把图片宽度交给业务组件去控制，初始化里不统一做限制，这样灵活性更高但风险也更高。

3.3 王者荣耀官网：去样式化 + 视觉引导优先的游戏阵地

王者荣耀 PC 官网的初始化跟电商两个站有明显的气质差异。它更接近游戏行业常用的"现代 reset + 设计系统前置"方案。特征包括：

html, body { height: 100%; /* 游戏官网喜欢满屏沉浸式视觉 */ } body { background: #1a1a2e; /* 深色背景作为品牌基调 */ }

游戏官网不是信息流，它的核心任务是做视觉展示和氛围渲染。所以初始化会对html, body { height: 100% }、对背景色直接落成品牌深色、对a的 hover 状态不预设颜色（因为每个活动页都有自己的主色调）。它做了更多的"去样式化"工作——把所有标签的默认样式清掉，然后交出控制权给具体页面。这与电商站"初始化里就要为业务提供默认外观"的思路是反着的。电商站是初始化尽量给一个可用默认值，游戏站是初始化尽量保持中立让活动页自由发挥。

这种差异的本质是：电商站的初始化要承担"开箱即用"的职责，因为后面接的是几十上百个业务团队写的复杂组件；游戏官网的初始化则更接近一个纯 reset，把一切不确定的样式归零，确保视觉可以在零干扰的基础上自由构建。

3.4 三站初始化方案横向对比

表格看着直观，但我要提醒的是：这些差异不是哪家的代码一定更好，而是它们面对的产品约束不同。你做个人项目或者公司官网时，应该先问自己"我的产品更像哪一类"，再决定初始化方案往哪个方向偏。

4. 从这三个站的初始化里，能抄走哪些真正有用的东西

前面讲了不少现象，现在给可落地的结论。逐个把"能抄的"和"不能乱抄的"分开说。

4.1 可以直接抄走的五条规则

第一，box-sizing: border-box全量应用。这个不用犹豫，现代前端项目基本都该这么做。第二，链接去掉默认下划线，颜色跟随父级。这条在绝大多数业务里都成立，尤其是电商和游戏官网这种重视觉场景。下划线应该只出现在正文长文的阅读场景里，默认去掉，需要时再加。第三，列表去圆点。即使你的页面里列表用得少，这一条成本极低，写上没坏处。第四，表单控件继承字体。这条能避免按钮、输入框和正文字体不统一的尴尬。第五，图片去掉边框并统一垂直对齐方式。特别是vertical-align: middle，能直接解决图片底部空白的老大难问题。

4.2 需要按场景调整的三条规则

第一个是*通配清零的范围。如果你做的是内容型产品（博客、文档、新闻站），* { margin: 0; padding: 0 }会把标题、段落的天然间距全部干掉，后期要补一堆间距样式，性价比不高。这种场景更适合用只清差异性、保留合理默认值的方案，比如 normalize.css。如果你做的是电商后台或工具型页面，*清零的利大于弊。

第二个是 body 默认字号。电商站用 12px 是因为信息密度要求高，但你做面向普通用户的 C 端产品时，12px 会显得页面很 "old school"，现在的趋势是 14-16px 起步。所以你应该把初始化里的 font-size 调成自己产品的基线，而不是照抄京东的 12px。

第三个是html { font-size: 100px }这条天猫写法。只有当你的项目确实要用 rem 做响应式时，这个根字号才有意义。如果你一直用 px 或 vw，加这个反而会造成"为什么我的 rem 这么大"的困惑。不要为了抄而抄。

4.3 一个容易忽略的重要配置：-webkit-text-size-adjust

三站的初始化里都出现过与文本缩放相关的处理。移动端浏览器在横竖屏切换时，默认会对文字做自动放大调整，这在某些场景下会破坏样式。业界的通用做法是：

html { -webkit-text-size-adjust: 100%; }

设成 100% 等价于告诉浏览器"别自动缩放我的文字，按实际设的字号渲染"。这一条在 PC 端项目里看似用不上，但随着响应式布局越来越普及，一个页面要兼顾不同视口宽度，加上这条能提前杜绝很多移动端适配的字体异常问题。

4.4 抄之前建议做一次 "清除兼容性包袱" 的裁剪

老项目抄来的初始化代码最大的问题是：里面可能有大量已经失效的历史 hack。比如_zoom: 1这种旧 IE 的块级格式化上下文触发方式、* html这种仅 IE6/IE7 识别的选择器、expression()这种老掉牙的 JS 表达式。这些代码在现在所有主流浏览器里解释到一半就被忽略，没有任何作用。你抄下来除了增加文件体积，还会让后续维护的人搞不清项目到底还要不要兼容老 IE。

我建议的做法是：抄完初始化代码后，全局搜索* html、_前缀、zoom、expression、filter这几个关键词，看到就直接删。删完以后在 Chrome、Firefox、Safari 里各过一遍，如果页面表现没有变化，说明这些确实是死代码。

5. 初始化之后的三个高频问题：body 字号、rem 计算、清浮动

初始化写完了不代表万事大吉，实际操作中还有几个和初始化强相关的高频问题，这里一起讲掉，因为这些问题的解法本质上就是初始化的一部分。

5.1 body 字号对子元素继承的影响，比你想象的更隐蔽

很多人在初始化里写了body { font-size: 14px }，但页面里部分模块的字号仍然不是 14px。原因可能出在：某些组件在根节点上显式写了 rem 或 em 字体，而 rem 的基准是 html 的 font-size，em 的基准是直接父级字号，两者的基准完全不一样。比如一个子组件写了font-size: 1.5em，而它父级的字号是 20px，那渲染出来就是 30px，不是你想象中的"body 14px 乘以 1.5 = 21px"。这个坑我在多个项目里见过。

初始化阶段推荐把根级字号策略定清楚：如果你的项目以 px 为主，那就避免在组件里使用 em；如果你的项目以 rem 为主，那 body 的 font-size 写成什么其实无关紧要，因为最终生效的是 html 的根字号。三站的初始化里其实都暗含了各自的单位策略，你抄的时候要把这层"单位策略"一并抄走，而不是只抄表象。

5.2 rem 计算混乱：根字体的两种主流方案

天猫那种html{ font-size: 100px }的做法有一个变种玩法，很多团队实际用的是媒体查询分段调整根字号：

html { font-size: 16px; } @media (min-width: 375px) { html { font-size: 18px; } } @media (min-width: 768px) { html { font-size: 20px; } }

这种做法本质上是在不同屏宽下统一缩放 rem 的值。跟"JS 动态设置根字号"相比，它的优势是写起来简单、没有闪跳，劣势是只能在断点处突变，不是连续缩放。我在电商大促活动页里见过用后者的，也见过用前者的。如果你要维护一个长期项目，建议在初始化阶段就选定一种方案并写进注释里，避免后来的人两种方案混用，导致间距忽大忽小。

5.3 clearfix 已经进化成更现代的方案

京东初始化里内置的 clearfix 是浮动时代的产物。现在 Flexbox 和 Grid 已经是绝对主流，浮动布局基本退出历史舞台，clearfix 的使用场景已经非常稀少。但电商页里偶尔还会遇到第三方接入的旧组件用浮动，所以 clearfix 作为工具类保留一颗也无妨。不过我更推荐用现代方案解决父容器高度塌陷问题，那就是给父容器直接声明display: flow-root，这个属性就是专门用来让父容器包含浮动的，副作用比 clearfix 更小。初始化代码里可以预留这样一个 class：

.clearfix { display: flow-root; }

这一行就能替换掉过去那种必须配合::after才能生效的长段写法。实测在 Chrome、Firefox、Safari 里的表现稳定。不过有一点要注意：display: flow-root会创建一个新的格式化上下文，某些极端场景下可能影响子元素的某些布局行为。如果遇到怪问题，再退回传统的 clearfix 写法也不迟。

6. 两个补充场景：多语言站点和可视化建站工具的初始化注意点

标题说的是京东、天猫、王者荣耀，但做前端不可能只做这类型的站。两块延伸场景，一并讲一下，都是从这三个站的初始化实践里衍生出来的提醒。

6.1 多语言站点：中文字体和西文字体的交错继承

京东、天猫曾经都做过国际化站。多语言站点的初始化比单中文站点多一个要求：字体栈里必须同时考虑目标语言的字形。中文的font-family里同时带上英文优先字体是常规操作，但反过来，一个英文为主的站点如果要对中文用户做适配，字体栈写法就得调整。这种时候，初始化文件里不能只写一套字体现成的栈，而是应该给html和body分别定义国际通用字体栈与中文补充字体栈，再配合lang属性选择器做差异化加载。

我看到过不少多语言项目直接把中文站的初始化拿过去用，结果英文页面上的数字和字母全被微软雅黑渲染，显得非常臃肿。正确做法是英文环境下优先Helvetica Neue、Arial，中文环境下再落到微软雅黑或苹方。这些细节都应该在初始化阶段定好，而不是等到每个组件里去覆盖。

6.2 可视化建站工具：初始化层级要配合运行时注入

有些企业级后台会长出可视化建站能力（拖拽生成页面）。这种场景下，从这三个站总结出来的初始化方案有一个问题：初始化一旦指定了h1 { font-size: 100% }这类强规则，可视化编辑器里设置的某些内联样式会跟初始化发生"隐形对抗"。因为编辑器生成的样式通常以内联方式插入，内联样式优先级高于外部样式表，这没问题；但编辑器为了统一产出而生成的兜底类会同时依赖外部样式表，此时初始化太强硬，会导致编辑器控件的默认显示和最终产出页面的显示不一致。

我的处理经验是：可视化建站项目里，初始化文件只做box-sizing、margin padding 清零和基础字体继承这类"安全规则"，凡是涉及具体字号、颜色、行高的规则尽量不要写在初始化层，而是交给主题配置层去控制。这样主题切换时才不会因为初始化代码的影响而出现整体偏差。这一点京东和天猫的内部运营活动系统里体现得很明显，它们的初始化相对克制，因为活动页面可能由多套模板生成，初始化过重会导致模板之间互相打架。

7. 实测验证建议：怎样用开发者工具演算一套初始化方案

以上总结的规律和建议，最终还是要落到"你能自己验证"。这里给一个我用过的实操路径，照着这个路径可以观察京东、天猫、王者荣耀 PC 端的实际样式表现，验证哪些初始化规则真的发挥了作用。

首先，打开站点首页后，选中<body>标签，看浏览器 Computed 面板里的 font-family、font-size、line-height、background-color 几项，能直接读出它们的 body 级初始化参数。其次，随便选中一个<a>标签，看 text-decoration 和 color，能验证链接初始化规则。再其次，找一个<ul>列表，看 list-style 和 padding 值，能验证列表是否被清过样式。然后，选中一张img，看 vertical-align 的最终计算值，能确认图片垂直对齐方式。最后，在 Console 里执行一条脚本检查会有帮助：

// 检查页面上所有非空元素的默认 margin/padding 是否已被清零 const nodes = document.querySelectorAll('*'); let uncleaned = 0; nodes.forEach((el) => { const style = getComputedStyle(el); if (style.marginTop !== '0px' || style.paddingTop !== '0px') { uncleaned += 1; } }); console.log('未清零的元素数量：', uncleaned);

注意，这里"未清零"不是指初始化做得不好，而是指初始化保留了合理默认值的元素（比如段落、标题、表格单元格）。这个脚本的真正作用是帮你观察"你的初始化到底覆盖到了什么程度"，覆盖太多还是太少，一目了然。

验证完这三家的页面表现之后，我建议你做一件事：把它们的初始化方案各自剥出最精华的一条——京东的 clearfix 工具类、天猫的根字号策略、王者荣耀的媒体元素去样式化——然后结合自己项目的实际情况，重组一套自己的初始化。直接照搬任何一家都不是最优解，因为你的产品既不是另一个京东，也不是另一个王者荣耀，但它们的取舍逻辑一定值得参考。