中文字体栈跨平台实践：font-family配方、字重行高与排查-北京尧图网络

做前端这些年我改过最久的一行 CSS 不是什么复杂动画而是一行font-family。西文那一句-apple-system, Helvetica Neue, Arial, sans-serif抄了十年也没出过事可一旦换成中文同样的写法在不同机器上能长出三种完全不同的样子同样 16px 的正文在 macOS 上是苹方那种清瘦、收得紧的字面换到 Windows 上命中微软雅黑字一下胖了一圈行距显得局促再换到 Android又变成思源黑体笔画粗细、标点宽度、数字宽度全都不一样。最难办的是评审会上有人拿其中一台机器的截图说就按这个效果来,而你手里的另外两台设备从物理上就做不到。这篇文章想解决的就是这件事把中文字体栈写对、写稳、写到跨平台看起来差不多。适合三类人看——写 CSS 的前端、做跨端 App 或小程序或 HTML 邮件的开发者以及被中英混排、标点挤压、粗体发虚折磨过的排版洁癖。我会讲清楚中文字体栈为什么不能照抄英文那一套把各平台自带的中文字体家底列清楚给出四套我自己常年直接抄的font-family配方再把配套的字号、行高、字重参数和排查链路一并交代。看完你至少能做到一件事不再靠猜来决定那串字体名怎么写。1. 中文没有通用字体栈同一段 CSS 在三端会长成三样1.1 西文那一行之所以能通用是因为它赌对了两件事英文站点的字体栈之所以常年只用一行就够背后其实赌了两个前提。第一个前提是字形差异足够小Helvetica、Arial、Segoe UI、Roboto、San Francisco 这几套无衬线字体x 高度接近、字宽接近、笔画粗细接近同一个 16px 下视觉体积差不了多少用户在哪个平台看到都不会觉得别扭。第二个前提是字重齐全真正需要加粗、变细、做斜体的时候系统里总能找到对应的字重文件浏览器不用自己动手造。这两件事在中文里都不成立。中文字体的字形密度高得多同样是 16px汉字的字面基本撑满整个 em 框而拉丁字母的视觉体积只有 em 框的六七成所以中文看起来天生比英文大、比英文挤。再加上各家厂商的黑体在字面率、笔画粗细、收笔方式上的审美取向完全不同苹方偏细长挺拔微软雅黑偏饱满圆润思源黑体介于两者之间但笔画更直。这些差异在英文里是可以忽略的噪声在中文里就是一眼能看出来的画风变化。1.2 中文字体没法塞进 font-face这才是所有问题的源头西文可以随便font-face引一个 30KB 的 woff2所以英文站点的字体栈其实只是兜底方案,真正生效的往往是那个自定义字体。中文不行一套覆盖 GB2312 常用字的黑体woff2 压缩之后也得三五百 KB全量字形几万个汉字加符号轻松上到几 MB 到十几 MB。让用户为了看你一篇文章下载 5MB 字体等于直接劝退。于是中文字体栈的本质就变了——它不是优先用我的字体失败时兜底,而是全程都在用别人机器上已有的字体我只能控制用的顺序。这就意味着你能做的事情只有两件第一把顺序排对让每个平台都命中它自己最合适的那个字体第二字体之外的地方字号、行高、字重、间距跟着字体一起调把差异压下去。1.3 字重断层和中文化斜体是两个必须提前知道的事实微软雅黑这套字体实际上只有三个可用字重Light、Regular、Bold。你写font-weight: 500或者600浏览器做的第一件事是就近匹配,很可能直接给你渲染成 Regular也就是你的设计里那句半粗强调在 Windows 上根本没体现写font-weight: 800的时候某些浏览器会拿 Bold 再做一次加粗笔画就糊在一起了。而苹方有 Ultralight 到 Semibold 六个字重同样的 600 在 macOS 上是一个非常漂亮的 SemiBold。同一份 CSS两端一个字重对得上、一个字重对不上这件事在做设计系统的时候特别容易被忽略。中文化斜体更麻烦。汉字本身没有斜体形态font-style: italic在中文上得到的永远是浏览器按大约 12 度硬拗出来的合成斜体字口变形、笔画错位观感极差。所以中文里表达强调这件事宁可换字重、换颜色、加左侧色条也不要用italic。真要禁止浏览器乱来可以显式写font-synthesis: none代价是那些都没有真字重的情况会退回 Regular 而不是被合成。2. 把各平台的中文字体家底盘一遍哪些能写、哪些是坑2.1 Windows微软雅黑是主线但要记住它的变体和老系统Windows 上的中文字体可用性在 Vista 之后基本稳定下来了系统 UI 和网页默认栖息在微软雅黑Microsoft YaHei上Windows 10 之后界面用的是一个变体Microsoft YaHei UI两者字形几乎一样但字距和行高微调过网页里通常不需要单独写它。老系统XP 时代身上是中易宋体 SimSun这个字体在小字号下笔画细得像断线屏显效果很差但因为出现在一些老设备上宋体系的栈里还是得留着它兜底。除此之外 Windows 上还常驻着几套字体黑体 SimHei比微软雅黑更方正、字面更大、等线 DengXianOffice 2016 之后随装的偏现代但笔画偏细、楷体 KaiTi、仿宋 FangSong。等线和楷体在网页里基本不用但如果你的产品里要做公文体或者手写感的装饰标题它们是可以直接调用的现成资源。一个容易踩的点微软雅黑的字面率比苹方大同一font-size下在 Windows 上看起来更饱满。如果你的设计稿是在 macOS 上做的直接拿到 Windows 上看会显得字变大了一号,行高必须同步放宽。2.2 macOS 与 iOS苹方接管了 2015 年之后的所有中文macOS 10.11 之后系统中文默认字体从华文黑体STHeiti / Heiti SC换成了苹方-简PingFang SC。苹方有六个字重字面清瘦、字距舒服是到目前为止我认为最适合屏显正文的中文黑体之一。iOS 上同理新系统全部是苹方只有很老的设备会退回 Heiti SC。除了苹方mac 上还常驻着冬青黑体简体中文Hiragino Sans GB在 10.10 及更早的系统上它是很多网站的中文默认字体现在虽然不再是主角但作为一个中间兜底还是很有价值——它的字形比苹方更接近传统黑体。衬线方向有宋体-简Songti SC和华文宋体STSong装饰方向有楷体-简Kaiti SC、华文楷体STKaiti、圆体-简Yuanti SC。这里有个很多人不知道的细节在 macOS 上写-apple-system浏览器的系统 UI 字体San Francisco会自动把中文字符交给苹方渲染。所以你在 mac 上写不写PingFang SC效果一样但一旦你希望显式锁定中文字体比如你想让中文走冬青黑体而不是苹方就必须把中文字体名单独写出来。2.3 Android、Linux 和国产系统思源黑体阵营但名字有好几个Android 从 5.0 之后用的中文黑体是思源黑体体系字体名通常显示为Noto Sans CJK SC。早期的 Android 用的是一套更细的Droid Sans Fallback字形质量和现在的差距很大但留存设备不多。等宽方向上需要特别说明一点Android 和 Windows 上都没有真正意义上的中文等宽字体代码块里出现中文字宽一定是比例宽度不可能像英文那样对齐到两个字符位。Linux 桌面最稳的选择是Noto Sans CJK SC但很多精简发行版不一定装了它可能只有文泉驿微米黑WenQuanYi Micro Hei或者文泉驿正黑WenQuanYi Zen Hei,所以字体栈末尾一定要把它写上。此外部分国产手机系统会预装自研的现代黑体字体名带品牌前缀字形观感和思源接近这类字体不用专门写交给末尾的sans-serif兜底就行。最后是思源黑体 / 思源宋体的双名问题这是 Linux 上最容易出问题的地方字体家族常见安装名说明思源黑体Source Han Sans SC与Noto Sans CJK SC同一套字形的两个发布名发行版装的可能只是其中一个思源宋体Source Han Serif SC与Noto Serif CJK SC同上微软雅黑Microsoft YaHei与微软雅黑同一字体的中英文名建议两个都写苹方PingFang SC只有英文名写中文名无效3. 四套我常年直接抄的 font-family 配方3.1 通用正文栈西文优先、中文兜底的分层写法这是我放在 CSS 变量里、几乎每个项目都用的那一套:root { --font-sans: -apple-system, /* macOS / iOS 系统 UI 字体中文自动落苹方 */ BlinkMacSystemFont, /* 旧版 Chrome 在 mac 上的同一入口 */ Segoe UI, /* Windows 的拉丁字形 */ PingFang SC, /* macOS / iOS 中文 */ Hiragino Sans GB, /* 老版本 macOS 中文兜底 */ Microsoft YaHei, 微软雅黑, /* Windows 中文 */ Source Han Sans SC, Noto Sans CJK SC, /* Linux / Android 中文 */ WenQuanYi Micro Hei, /* 精简 Linux 兜底 */ sans-serif; } body { font-family: var(--font-sans); }这套写法的核心逻辑是分级:第一级是系统 UI 字体入口负责让拉丁字符拿到最贴合平台的西文字形mac 上 SF、Windows 上 Segoe UI第二级以上全部是中文字体负责在拉丁字体没有汉字字形时接管。浏览器解析字体族的规则是逐字符从前往后找所以西文字体一定放前面中文字体一定放后面——顺序反了中文字体里的拉丁字形会先被命中结果就是英文变成中文黑体里那种半宽、偏方正的拉丁字母看起来特别业余。有一点值得强调Microsoft YaHei和微软雅黑我习惯两个都写。虽然现代浏览器对中文族名的解析已经没问题但在一些老旧内核和部分 App 的内嵌 WebView 里中文族名反而更稳两个都写上不会有任何副作用。3.2 标题栈中文提到前面字重固定在能对得上的档位标题的情况和正文相反——标题里中文占比更高而且往往字数少、字号大多一次字体回退判断的代价被放大了。所以标题栈我会把中文字体提到前面.title { font-family: PingFang SC, Microsoft YaHei, 微软雅黑, Source Han Sans SC, Noto Sans CJK SC, -apple-system, Segoe UI, sans-serif; font-weight: 600; }为什么把中文提前因为标题里绝大多数是汉字PingFang SC第一个命中拉丁字符交给它内部的拉丁部分渲染苹方自带的拉丁字形质量并不差。更重要的是把中文放在前面之后font-weight: 600在苹方上能拿到真正的 SemiBold在微软雅黑上会掉到 700Bold——这是我实测下来最能接受的结果比掉到 Regular 强得多。如果你的设计对 600 特别敏感可以按平台写两套值.title { font-weight: 600; } supports (-webkit-touch-callout: none) { /* 走 iOS/macOS 分支时保持 600 */ .title { font-weight: 600; } }说实话这种supports探测字体能力的写法很脆弱我更多是在设计阶段就定死标题只用 400 和 700 两档避开所有中间字重跨平台表现最稳定。3.3 代码块栈接受中文必然不等宽这个事实代码块是唯一一个我必须坦白承认做不到完美的地方pre, code, kbd, samp { font-family: ui-monospace, /* 现代浏览器的等宽入口 */ SFMono-Regular, /* 旧 Safari */ SF Mono, /* macOS 自带 */ Menlo, Monaco, /* macOS 老牌等宽 */ Consolas, /* Windows 自带屏显最舒服的等宽之一 */ Liberation Mono, /* Linux */ Courier New, monospace; font-size: 0.9em; font-variant-east-asian: proportional-width; letter-spacing: 0; }font-variant-east-asian: proportional-width这一行是这套写法的关键也是很多人不知道的一招。它让东亚字符按比例宽度渲染而不是按传统的全角宽度渲染效果是代码注释里的汉字不会一个占两个字符位、把一整行撑得稀稀拉拉。这个属性在不同浏览器上的支持程度有差异但即使不生效也不会报错属于用了不亏的类型。如果你对代码块里的中文对齐有强需求唯一的正解是引入一套第三方中文等宽字体比如基于等宽思路制作的更纱黑体这类把它的家族名放在Consolas之后。但要做好心理准备这套字体动辄十几 MB必须做子集化否则首屏会很难看。3.4 宋体栈和楷体栈字号一定要抬上去需要书卷气的场景长文阅读、文章详情、报告导出我会切到宋体栈.prose { font-family: Georgia, Times New Roman, Songti SC, 宋体-简, SimSun, Source Han Serif SC, Noto Serif CJK SC, STSong, serif; font-size: 17px; line-height: 1.9; }宋体的问题在于笔画极细横画只有一两个像素宽在低分辨率屏或者系统缩放不是 100% 的机器上非常容易糊。所以宋体正文的font-size我从来不敢低于 16px行高也一定比黑体再抬 0.1 到 0.2。另外 Windows 上的 SimSun 小字号观感明显差于 mac 上的宋体-简如果你要照顾 Windows 用户宋体方案最好只在字号足够大的长文场景用短文本和 UI 一律走黑体。楷体栈更简单用在引言、签名、装饰性标题上.handwriting { font-family: Kaiti SC, STKaiti, KaiTi, 楷体, FangSong, 仿宋, serif; }这里多留了一个仿宋兜底因为有些精简系统上楷体缺失仿宋的相对观感最接近。4. 字体栈写完只做了一半字号、行高、字重才是决定观感的另一半4.1 中文字号行高的经验配比英文站点正文 16px / 1.5 是通行做法直接搬到中文上会显得挤得难受。原因前面说过汉字字面撑满 em 框视觉高度天然比拉丁字母大同样的行高下中文的行间距看起来更窄。我这些年固定下来的配比大致是这样场景font-sizeline-height备注长文正文16–17px1.75–1.9黑体取 1.75宋体取 1.9列表、卡片描述14px1.6再低汉字会粘在一起一级标题28–32px1.35中文标题行高别超过 1.4次级标题18–20px1.45代码块13–14px1.7中文注释多的话再抬到 1.8按钮文字14–15px1.2单行行高只影响垂直居中另一个容易被忽略的点是font-size的写法。用rem比px更稳因为用户如果改了浏览器默认字号rem会跟着放大而px不会。但绝对不要在嵌套元素上用百分比叠乘font-size: 90%,叠两层之后 16px 变成 12.96px中文在这个尺寸下笔画开始糊。现代浏览器可以用clamp()做自适应比如font-size: clamp(15px, 1rem 0.2vw, 18px),这样窄屏不会小到看不清、宽屏不会大到一行放不下几个字。4.2 字重选择宁可只用两档也别指望中间值我在做设计系统时定过一条规矩中文字重只用 400 和 700 两档特殊情况加一个 300仅用于超大标题。理由很实际——你无法保证用户设备上有 500 或 600。苹方有微软雅黑没有思源黑体的可变字体版本有但静态版本可能只装了部分档位。一旦你依赖了 600在缺字重的平台上浏览器要么就近取 500没有就取 400要么合成一个假的 SemiBold 出来两种结果都不可控。如果真的要用中间字重配套写一句.strong { font-weight: 600; font-synthesis: none; /* 禁止浏览器合成粗体缺字重时老老实实退回 400 */ }font-synthesis: none的取舍要讲清楚它能避免合成粗体发虚这个经典问题合成粗体是在原字形上横向加粗汉字的横竖笔画会粘连但代价是缺字重的平台会直接显示为常规体强调感消失。所以我的做法是——重要信息别只靠字重区分同时给颜色或者背景这样即使字重掉了也不会丢失信息层级。还有-webkit-font-smoothing: antialiased这个老生常谈。它在 macOS 上会让苹方渲染得更细视觉上更接近设计稿里那种清瘦感在 Windows 上它完全无效那边的渲染走的是另一套机制text-rendering: optimizeLegibility也基本没用。所以它是一个只在 mac 上生效的偏方,别指望它解决跨平台观感差异。4.3 中英混排的间距、断行和标点中英混排好不好看字体栈只占三成剩下七成在这些细节上间距letter-spacing: 0.01em ~ 0.02em是我常用的微调区间能让中文稍微松一点看起来不那么密。超过 0.05em 汉字会散架。断行overflow-wrap: anywhere应对超长英文串和 URL 撑破容器中文本身可以在任意字间断行所以不需要word-break: break-all那样会把英文单词也切碎。标点禁则line-break: strict可以让浏览器遵守更严格的中文断行规则避免句号、逗号、右括号出现在行首。这个属性在中文排版里价值很高但很多人不知道。中英之间要不要加空格CSS 层面没有可靠的自动方案text-autospace的兼容性目前还不行。实际项目里我是在内容侧处理——富文本渲染时用正则在中英文边界插入一个thinsp;或者一个带margin的span或者在编辑规范里直接要求作者手打空格。全角标点和数字混排中文全角逗号后面接阿拉伯数字时视觉上会多出一个空档这是全角标点的固有宽度导致的只能靠内容侧统一规范比如数字一律用半角、标点一律用全角别指望 CSS 修。5. 声明了字体却没生效从 DevTools 到截图的完整排查链路5.1 先确认字体名有没有写错这是最高频的原因而且症状很迷惑人整个页面的字体都变了看起来像是某条规则没生效,其实是字体族名拼错了导致整条链从那一项开始失效。三个检查点第一带空格的族名必须加引号。Microsoft YaHei不加引号在多数浏览器里也能解析但像Source Han Sans SC这种三段式的名字不加引号在部分解析器里会被拆成三个独立族名等于写了三个不存在的字体。养成习惯只要族名里有空格一律加双引号。第二中英文名双写。Microsoft YaHei, 微软雅黑这种写法不冗余某些内嵌 WebView 只认其中一个。第三拼写要照官方写法。字体族名匹配本身不区分大小写但拼错一个字母就是另一个字体。PingFang SC不能写成PingfangHiragino Sans GB不能漏掉Sans。5.2 用 Rendered Fonts 面板看到底用了谁Chrome 和 Edge 的 DevTools 里有一个非常实用的面板选中元素之后在 Elements 面板右侧的 Computed 标签页拉到最下面有一块Rendered Fonts,它会明确告诉你这段文字实际是用哪个字体渲染的、每个字体贡献了多少个字形。这是排查字体问题的第一手证据比猜快一百倍。如果它显示的是你栈里最后一个sans-serif,说明前面所有字体都没命中如果显示的是某个你根本没写的字体比如系统默认的宋体说明你的 CSS 压根没应用上去查选择器优先级或者样式被覆盖。还有一个细节如果它显示某个字体但只贡献了个位数字形通常是那个字体只提供了拉丁字符汉字是被后面的中文字体接管的属于正常现象。5.3 三端截图对比法把差异量化出来我处理跨平台字体问题有一套固定的土办法很笨但特别有效。写一个测试页里面放一段固定的对照文本覆盖中文、英文、数字、中英混排、全角标点、括号、时间格式、货币符号p classsample 中文测试 ABC abc 123 。「」【】 15:30 99.00 iPhone 15 Pro Max / Windows 11 / Android 14 /p然后在这段文字上分别套用你要验证的字体栈在 macOS、Windows、Android真机不是模拟器各截一张图字号统一 16px、行高统一 1.75、宽度统一 600px把三张图裁成同样尺寸并排放。这么做的价值在于你能直接看到三件事同一个字号下三端的字面大小差多少、标点在行首尾的表现差多少、中英混排的间距差多少。有了这三张图你调font-size和letter-spacing就有了明确的目标值而不是我觉得 mac 上好看就这样定。5.4 网页字体中文字体真要引就得做子集化如果设计要求必须用一套系统里没有的中文字体比如某个品牌定制的黑体那font-face是唯一的路但必须做三件事否则性能会崩第一子集化。按常用字表3500 常用汉字常用标点拉丁字母数字切出最小集合woff2 格式下大概能压到几百 KB。如果内容里有生僻字或者人名地名要额外补一份扩展字表。第二按 unicode-range 切片。把大字体切成若干个按码位区间划分的文件浏览器只会下载当前页面实际用到的那些片。这个策略对中文特别有效因为大部分页面用到的汉字其实只有几百个。第三font-display: swap加上尺寸补偿。swap让文字先用系统字体渲染自定义字体下载完再换避免白屏无字FOIT。但切换瞬间会跳动可以用size-adjust、ascent-override、descent-override把自定义字体的度量调整到和兜底字体接近跳动会小很多。font-face { font-family: Brand Sans; src: url(/fonts/brand-sans-common.woff2) format(woff2); font-display: swap; unicode-range: U4E00-9FFF, U3000-303F, UFF00-FFEF, U0020-007E; size-adjust: 98%; }5.5 用户侧还有一堆你控制不了的变量有些字体不对根本不是你的问题而是用户环境现象可能原因处理方向只有个别用户字体异常浏览器最小字号设置或系统字体缩放如 Windows 125%用rem布局避免像素级写死全部文字变了一种陌生字体用户装了字体替换类插件或系统主题改了默认字体无解靠字体栈末尾兜底粗体发虚、笔画粘连合成粗体font-synthesis: none或改用 700中文标点挤成一团全角标点窄容器 text-align: justify调line-break、放宽容器、关掉两端对齐首屏文字闪一下才变正常网页字体加载没做度量补偿font-display: swapsize-adjust这张表我能背下来是因为每一个坑我都至少踩过一次。其中最小字号那个最阴——你按 12px 设计的小字备注在很多用户机器上会被强制放大到 14px 甚至 16px布局直接错位。这里没有完美的解法只能设计时就不依赖 12px 以下的字号。6. 几个反复验证过的结论和长期维护习惯6.1 别在 body 上写死单一中文字体我见过太多项目直接body { font-family: Microsoft YaHei; },在 Windows 上确实好看但 mac 用户、Android 用户、Linux 用户看到的全是回退字体。正确做法永远是把字体栈定义在:root的 CSS 变量上body只引用变量。这样后续要加字体、换顺序、按平台打补丁都只改一处。:root { --font-sans: /* 一长串 */; --font-serif: /* 一长串 */; --font-mono: /* 一长串 */; } body { font-family: var(--font-sans); } .prose { font-family: var(--font-serif); }变量化的另一个好处是能在主题切换、暗色模式、导出场景里直接换一整套字体不用去找散落在各处的font-family。6.2 断点要跟着字体走不要跟着设备宽度走响应式里常见的错误是768px 以下字号降到 14px,但真正该决定字号的是这个尺寸下用什么字体、一行能放多少汉字。中文一行 25 到 35 个字是阅读舒适区超过 40 个字眼睛回扫会累低于 15 个字断行太频繁节奏乱。所以我会先按容器宽度算字数容器 600px / 字号 16px ≈ 37 字偏多把字号提到 17px 或者把容器收到 560px容器 320px / 字号 14px ≈ 22 字偏少行高抬到 1.75 补回来。这个算法比记断点有用得多。6.3 设计稿里的字体名不等于生产环境的字体名设计稿上写着思源黑体 Medium,你不能直接往 CSS 里写font-family: 思源黑体。生产环境要写的是Source Han Sans SC, Noto Sans CJK SC,因为大多数系统装的是后者。同理设计稿写苹方中黑,你要翻译成PingFang SC加font-weight: 500,并且提前想好这个 500 在 Windows 上会掉成什么。交接的时候我会把设计稿字体名 → CSS 字体栈 → 各平台实际字重做成一张对照表给设计避免来回返工。6.4 真机验证这件事没有捷径模拟器看字体是最不可靠的因为它用的还是宿主机的字体系统。Android 模拟器永远显示宿主机上的字体iOS 模拟器在某些版本上和真机的中文字体渲染也有差异。我吃过一次亏在模拟器上看着完美的行高到真机上因为系统字号缩放偏了一整行。从那以后只要涉及字体栈的改动我一定在至少三台真机上看一眼一台苹果设备、一台 Windows 机器、一台安卓机。这个成本远低于上线后被人截图吐槽。最后分享一个小习惯我会在项目里放一个fonts-test.html,里面就是前面那段对照文本把项目里所有字体变量各套一遍一行一个。改字体栈的时候打开这个页面三端各过一遍五分钟能看出所有问题。这个东西比任何文档都管用尤其是接手别人的项目、想搞清楚这套字体栈到底在哪些平台真的生效的时候。

中文字体栈跨平台实践：font-family配方、字重行高与排查

相关推荐

DevOps时代测试工程师的转型与技能提升

2026年开源AI Agent工具全景与生产级实践指南

美赛B题高阶建模：干旱建模、分层供需与NSGA2多目标权衡

更多资讯

pi-interactive-subagents 内置 Agent 团队深度剖析：planner、scout、worker、reviewer 六名专家如何分工协作

Redwood Service 层实战指南：Service Validations 与服务缓存全覆盖，快速搭出毫秒级业务层

样章-第08讲-用状态机管理设备生命周期

Folia PWA 手机化完整指南：3 分钟把全屏歌词动画播放器装进主屏幕

mermaid-live-editor：免费在线 Mermaid 图表编辑器，几行文本即可预览、导出并分享

Sandboxie 启动失败修复指南：5 分钟恢复驱动、服务与沙箱的完整教程

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？