NextJS 里的 FontAwesome 巨大图标：我如何从样式异常看见 SSR 边界
我以前遇到过一个很典型的 NextJS 问题：本地看起来正常的 FontAwesome 图标，到了页面加载时突然变得巨大。
第一次看到这种现象，很容易把它当成 CSS 小问题。
但后来我发现，这类问题真正提醒我的不是“图标怎么调小”，而是：在 NextJS 这类 SSR 框架里，样式注入顺序、构建模式和客户端渲染边界都需要被认真对待。
一个图标变大，只是表面现象。
背后是样式没有在正确的时机进入页面。
我为什么会记下这个问题
前端问题有一种很消耗人的地方：它经常不是完全坏掉，而是“看起来怪”。
FontAwesome 的图标异常就是这种问题。
图标还在，DOM 也在，代码没有明显报错，但页面一闪或者直接显示成不合适的尺寸。
如果只是临时调
font-size，也许能压下去。但这种修法会让我不踏实。
因为我没有处理样式来源，只是在结果上盖了一层补丁。
我希望自己在修 UI 问题时，先问一个问题：这是组件写错了，还是框架运行方式改变了样式加载顺序？
这类问题的核心
FontAwesome 的 React 组件需要对应的核心样式。
在普通 React 项目里，样式注入可能不明显。
但在 NextJS 里，页面可能先由服务端生成，再在浏览器端接管。
如果 FontAwesome 自动注入样式的时机和 NextJS 的渲染流程没有配合好，就可能出现图标短暂或持续显示异常。
我当时采用的处理方式，是显式引入 FontAwesome 样式，并关闭它的自动 CSS 注入。
常见写法是放在全局入口里，例如
_app.js 或当前项目约定的全局初始化位置：这段代码的意思不是“强行把图标变小”。
它真正做的是：我自己接管 FontAwesome 样式的加载位置，让 NextJS 能在更稳定的全局样式流程里处理它。
我会如何排查类似问题
以后再遇到图标、样式、布局在 NextJS 里异常，我会先按这个顺序看：
- 本地开发和生产构建是否表现一致。
- 页面刷新前后是否有闪动，判断是否和 hydration 有关。
- 组件库是否依赖全局 CSS。
- 全局 CSS 是否放在项目允许的位置。
- 是否存在自动注入样式和框架样式顺序冲突。
- 浏览器里查看目标元素最终拿到的 CSS 规则。
- 再决定是配置组件库，还是修自己的样式。
这套排查路径让我少走很多弯路。
因为前端样式问题最容易让人直接改视觉结果，但真正稳定的修法通常在加载链路上。
我对第三方组件库的边界
我不会默认认为第三方组件库有问题。
大多数时候，问题出在我没有理解它的使用前提。
FontAwesome 需要样式。
NextJS 对全局样式有自己的入口和限制。
当这两件事放在一起时，我就要明确谁负责注入样式，谁负责组织渲染。
我的边界是：
- 不在单个图标上到处写临时尺寸覆盖；
- 不把全局样式散落到业务组件里；
- 不在没有验证生产构建的情况下认为问题已经解决；
- 记录这类框架和组件库组合时的初始化代码；
- 升级 NextJS 或 FontAwesome 后，重新检查官方推荐写法和项目入口。
这些边界让一个小问题不会扩散成全站样式债。
这篇旧文现在对我的意义
这篇文章原来只是记录一个解决方案。
现在我更愿意把它看成一次关于 SSR 边界的提醒。
NextJS 不是普通的客户端 React。
很多“看起来只是 CSS”的问题，背后都可能和服务端渲染、客户端接管、构建产物和全局入口有关。
我希望自己以后处理前端异常时，不只盯着那个变大的图标，而是顺着它往后看：样式从哪里来，什么时候加载，谁在接管页面。
能看见这条链路，修问题才会更稳。
Loading...
