第一次看到 x86CSS 这个项目时我的第一反应是浏览器标签页开太多了。页面是一台“x86 处理器”的模拟仪表盘有寄存器、有 RAM、有解码器状态甚至还有指令流水线的高亮在“执行”。习惯性按下 F12 去看控制台JS 面板干净得让人怀疑人生——真正干活的是一份体积大到离谱的 CSS 文件。用纯 CSS 跑 x86 程序不需要 JS这标题看着像愚人节玩笑但它确实是真的。这篇内容我会把 x86CSS 的实现思路拆开揉碎它到底怎么用样式表模拟 CPU、为什么能做到同时对想动手复刻一个简化版的朋友给出一个可行的上手路径。相信我看完你会重新认识 CSS——它不只是给按钮调颜色的。1. 先别急着震撼x86CSS 到底“跑”了什么1.1 它没有跑操作系统它模拟的是 CPU 本身很多人一听“纯 CSS 跑 x86 程序”第一反应是网页里直接跑一个 Linux或者把一个小游戏塞进 CSS 里。实际上 x86CSS 做的事情更底层也更有意思它用 CSS 的层叠规则和选择器机制在浏览器里“造”了一颗简化版的 x86 CPU。所谓“运行程序”是指这颗虚拟 CPU 在执行一小段预置的 x86 机器指令比如简单的加法、数据搬运、跳转而不是在跑什么完整应用。这么说吧普通模拟器是用 JS 或 C 写一个虚拟 CPU 内核再用这个内核解释执行程序x86CSS 则是连“内核”都用 CSS 来表达——指令解码、寄存器翻转、标志位变化、执行结果输出全部由 CSS 的匹配结果和渲染状态来承载。JS 在这条链路里最多充当一个“点灯人”的角色真正的状态转移和逻辑运算都在 CSS 层完成。我自己拆这类项目时有一个习惯先看它的 HTML 结构。如果 HTML 里密密麻麻全是input[typecheckbox]和label那基本可以判断作者用的是前端圈赫赫有名的“checkbox hack”——这东西才是整座大厦的地基。1.2 为什么说“无需 JS”CSS 本身就是图灵完备的要理解 x86CSS 运行 x86 程序这件事绕不开一个理论前提CSS 结合 HTML 之后在可交互的浏览器环境下具备图灵完备性。图灵完备这个概念听着吓人翻译成人话就是只要给足时间和存储空间这套系统能计算任何可计算的问题。CSS 的图灵完备性并不是什么新鲜结论。早些年就有人用 CSS 画出过曼德博集合有人用纯 CSS 实现过康威生命游戏这些都是在“思维实验”层面证明 CSS 的表达力。x86CSS 比这些实验更进一步的地方在于它把 CSS 的表达力直接对齐到了一颗具体 CPU 的指令集上用最接近硬件的方式做了一次完整的“编译映射”。那 CSS 凭什么是图灵完备的核心是三件事状态存储、逻辑判断、循环/推进机制。状态存储可以由 checkbox 的:checked状态承担逻辑判断可以由选择器匹配承担循环推进可以由用户点击 CSS 动画承担。三样凑齐一台“人肉驱动样式表计算”的通用计算机就成立了。x86CSS 只不过是把这三样东西组合得足够系统化最终在浏览器里还原了一个可运行的 x86 指令流水线。2. 从零开始拆解纯 CSS 怎么模拟一颗 CPU2.1 数据从哪来checkbox 与 :checked 就是存储单元CPU 的核心是寄存器和内存寄存器的最小单位是 bit。在 x86CSS 里一个 bit 对应的就是一个 checkbox勾选代表 1未勾选代表 0。比如我要模拟一个 8 位的寄存器就在 HTML 里放 8 个 checkbox。光放 checkbox 还不够得让它的状态“可视化”——用 CSS 的:checked选择器去改变某个元素的样式把这个 bit 当前的值渲染出来。代码大概长这样div classregister idreg_ax input typecheckbox idax_bit0 input typecheckbox idax_bit1 input typecheckbox idax_bit2 input typecheckbox idax_bit3 input typecheckbox idax_bit4 input typecheckbox idax_bit5 input typecheckbox idax_bit6 input typecheckbox idax_bit7 div classbit-indicator span classb0/spanspan classb1/span... /div /div#ax_bit0:checked ... { background: #1a1a1a; }这里有一个细节很多人会忽略checkbox 天然提供了一个“长效状态”勾选之后只要不取消状态会一直保持。这正好对应了 CPU 寄存器“被写入后持续输出”的特性。跟用 class 切换模拟状态相比checkbox 状态无需任何 JS 干预就能被 CSS 反复读取这就是它成为核心存储单元的根本原因。多个 checkbox 组合起来就能表示字节、字、甚至整个内存空间。当然真实内存不可能全部放 checkbox否则 HTML 体积会爆炸所以 x86CSS 通常只会暴露一小块可读写的存储区域其余用预置常量代替。2.2 逻辑电路怎么搭CSS 选择器实现与/或/非门CPU 的加法、比较、跳转本质上都是逻辑门电路在做运算。要用 CSS 实现逻辑门核心技巧是把“选择器是否能匹配”当作逻辑运算的结果。举个例子我要做一个 AND 门有 A、B 两个输入两个 checkbox当且仅当两个都勾选时输出目标节点的背景色变化。CSS 可以这样写/* 仅当 a_check 和 b_check 同时被选中时结果节点变红 */ #a_check:checked #b_check:checked ~ .and-result { background: #dc2626; }OR 门就更好写用逗号分隔的选择器列表两个条件满足任意一个就命中。NOT 门则要靠:not()选择器实现#a_check:not(:checked) ~ .not-result { background: #16a34a; }有了与、或、非就能拼出更复杂的电路。最经典的是半加器一个 bit 的加法结果 A XOR B进位 A AND B。XOR 可以拆成“A 且非 B”或“非 A 且 B”在 CSS 里对应两段选择器的并集。于是两个 bit 相加这件事就变成了几个选择器组合的匹配结果。这个思路一开后面的 8 位加法器、比较器、标志位寄存器全都顺理成章。2.3 时钟从哪来点击制造脉冲动画制造连续执行真实 CPU 靠晶振产生时钟信号每个时钟上升沿推动一次状态转移。x86CSS 不能自己振荡它得靠“外部驱动”。最低成本的外部驱动是用户点击。你把“时钟”也设计成一个 checkbox用户每点一次就相当于给 CPU 打了一个时钟脉冲模拟器前进一步。单步执行模式下这种方式特别好用可以看到每一条指令执行前后寄存器的变化。但“用户手动打脉冲”太累了跑几十条指令会点到手抽筋。更高级的页面会加入 CSS 动画来模拟连续时钟定义一个循环动画让它反复切换某个时钟 checkbox 的状态比如 1 秒切换 4 次CSS 就会按照动画节奏周期性触发状态变更。这里有个性能问题绝对值得留意CSS 动画驱动的状态切换背后是浏览器反复做样式计算和布局。一个寄存器位宽 16 位、指令条数几十条的状态机一次完整周期就可能触发上万次选择器匹配。我在本地试过这类实现动画开着的时候风扇直接起飞。所以绝大多数 demo 都把默认时钟频率压得很低宁可让你手动点也不让浏览器一次性算爆。2.4 状态机怎么转层叠规则决定当前指令位置CPU 执行程序不是把每条指令并着算而是按程序计数器PC一条一条取、一条一条执行。这个“顺序推进”在 x86CSS 里是怎么实现的答案是把程序的每个状态预先写成不同的 CSS 规则分支通过控制一组 checkbox 的开关组合来决定当前激活哪个分支。举个粗糙的例子假设我的程序只有两条指令就需要两个状态。用两个 checkbox 表示当前指令指针pc0为 1 时执行第一条指令的译码逻辑pc1为 1 时执行第二条。CSS 写出两条并列的规则#pc0:checked ~ .stage-common { /* 规则 A第一个取指周期 */ } #pc1:checked ~ .stage-common { /* 规则 B第二个取指周期 */ }真正完整的 x86CSS 比这个复杂得多因为一条指令要拆成取指、译码、执行、写回多个阶段每个阶段又要考虑不同的操作数寻址方式。但本质思想一致CSS 层叠机制天然支持“同一时刻多条规则同时生效”作者通过精心设计的选中组合让同一个 DOM 节点在某一时刻只呈现出唯一正确的样式集合这就等价于状态机中“当前状态决定输出”的行为。3. x86CSS 的架构解剖从取指到执行的完整链路3.1 展示层寄存器面板和内存窗口是怎么渲染的打开 x86CSS 的页面最吸引眼球的就是那块“寄存器面板”。AX、BX、CX、DX、SP、BP、CS、DS、SS、ES还有 IP 和标志位寄存器全都像真实调试器一样显示出来。这些寄存器不是画死的静态文字而是由 checkbox 状态实时驱动的。每个寄存器的每一位对应一个 checkboxCSS 根据:checked状态决定对应 bit 的灯亮还是灭、显示 1 还是 0。你看到的每一次“寄存器变化”本质上是某个 checkbox 的选中状态变了连带触发了一长串选择器联动最终导致页面上十几个节点的样式同时刷新。内存窗口同理。一块连续的内存区域预先在 HTML 里挖好坑位每个字节的值由一个独立的 checkbox 组决定。这个设计很笨但很可靠唯一的问题是可扩展性极差——想要 1KB 内存就得在 HTML 里堆 8000 多个 checkbox页面体积和 DOM 复杂度都会失控。所以 x86CSS 在内存模拟上通常只保留一小块“可见窗口”程序能访问的空间远小于真实 x86。3.2 指令集子集x86 的哪个切片被真正实现x86 的完整指令集有上千条指令用 CSS 全量模拟是痴人说梦。x86CSS 选择的是 x86 架构中最有代表性的一小撮指令基本围绕数据搬运、算术运算和流程控制三类设计。MOV寄存器/内存之间的数据搬运ADD / SUB算术加法和减法同时影响标志位CMP / JMP / JZ比较和条件跳转配合标志位完成分支PUSH / POP栈操作用来演示内存和高地址方向的增长这些指令构建出一个最小但完整的“图灵机指令集”足以表达排序、循环这类控制流逻辑。单个指令的实现方式是把操作码、立即数、寄存器编号全部映射成 checkbox 位组合再用前面说的选择器匹配逻辑去触发对应的结果。它不是一个通用解释器而更像一个“针对这段程序专用定制”的硬接线电路——程序写死的那一刻CSS 规则也跟着定型了。3.3 CSS 文件为什么有上万行每一条指令都是一组规则从工程角度讲x86CSS 让我最震撼的是 CSS 文件的膨胀程度。一条简单的 ADD 指令可能要覆盖 16 种源操作数和目的操作数的组合一种组合又涉及取指、译码、执行三个阶段的中间状态每个状态还要处理对目标寄存器、标志位、内存窗口的样式输出。所有可能性乘起来就是海量的选择器规则。这意味着x86CSS 的作者基本是“人肉编译器”每新增一条指令支持就得手动编写并核对大量 CSS 分支。这里几乎不可能靠将来维护因为选择器的排列组合会随着指令增加呈爆炸式增长。我甚至怀疑作者曾经写了脚本来自动生成 CSS 规则就像现在很多 CSS-in-JS 库生成样式一样——否则一份纯手写的 CSS 要达到这个规模调试成本是不可想象的。3.4 与真实 CPU 的对应关系四级流水线的 CSS 映射真实 x86 CPU 有经典的五级流水线取指、译码、执行、访存、写回。x86CSS 做了一个抽象版把取指和译码合并成一个“前端状态”把执行和访存写回合并成“后端状态”。用 checkbox 组中的两位去编码当前处于哪个阶段stage_01, stage_10表示取指stage_00, stage_11表示译码stage_01, stage_11表示执行。然后在 CSS 中写“如果当前处于该阶段且当前指令的操作码是 XXX则点亮对应信号灯”。这一套写下来页面上呈现的就是一个可以“逐级观察”的迷你处理器。我记得在源码的展示里执行一条指令时前端的高亮会先从“取指”区域亮起再从“译码/执行”区域亮起像是真的看到一条指令在流水线里游走。这个体验做得相当有仪式感也非常适合教学——比 PPT 上讲一万遍冯·诺依曼结构都有说服力。4. 实际运行体验它能跑什么程序性能有多“感人”4.1 最经典的 Demo计算 2 3结果直接亮在页面上x86CSS 的示例程序都不会复杂最典型的是一个“计算 2 加 3 等于 5”的段子。程序用几条硬编码的 x86 机器码组成加载进“内存窗口”后通过手动点击时钟一步一步看到 AX 寄存器从 0 变成 2再从 2 变成 5。整个过程的仪式感很强你点一下IP 寄存器前进一格内存窗口对应的字节高亮译码区域显示当前指令的助记符执行区域把结果写回寄存器。这个过程相比 JS 模拟器最大的优势是“可见性”——因为所有状态都是显式渲染在页面上的所以每一步变换都看得清清楚楚。我拿这个给完全没有汇编基础的朋友演示过五分钟之内他就理解了“程序 指令 数据 状态”这句话。4.2 性能实测一次状态机转移的成本远超你的直觉如果你把这个项目当成“CPU 模拟器”去用性能会让人崩溃。在 CSS 里执行一个指令周期不是执行一次函数而是要等浏览器把整棵 DOM 树的样式重新计算一遍。选择器匹配的复杂度取决于 DOM 规模和规则数量当 CSS 规则上万条、DOM 节点上千个时一次:checked变化引发的样式重算耗时可能达到几百毫秒如果再叠 CSS 动画的自动时钟浏览器会频繁进入高占用状态。我实测时用手动点击模式跑 20 条指令每点击一次都要等一小段延迟才能看到结果刷新视觉上给人“卡顿”的感觉。这在 JS 模拟器里是不可想象的——一个轻量 JS 8086 模拟器每秒执行几十万条指令毫无压力。差距这么悬殊本质上不是作者优化不行而是 CSS 从根本上就不是为通用计算设计的。你强行让它做计算它就得付出“非本职工作”的代价。模拟方案指令吞吐量估状态可见性实现复杂度适合场景JS 解释器模拟器数十万条/秒需自行开发调试面板中等实用工具、学习教材WASM 模拟器更高需自行开发调试面板较高追求性能的场景x86CSS人类点击速度天然完整可见极高概念验证、炫技、教学演示4.3 和 JS 模拟器正面对比它根本不是为了“实用”很多人第一次看到 x86CSS 时会问这东西能替代 QEMU 吗能跑 Linux 吗答案是不能。它的价值完全不在“能用”而在“难以想象它竟然能实现”。从我接触过的前端冷知识项目来看x86CSS 更像一个“批判性设计”作品。它通过做到一件看似毫无意义的事反向揭示了 CSS 这门语言的真实极限CSS 的表达力比你想象中强得多但代价也比你想象中大得多。它在提醒我们当一门语言被推近图灵完备边界时可读性、性能、工程可维护性会如何急剧劣化——这是一个非常有趣的工程边界实验。5. 边界、局限与前端思维的启发5.1 为什么官方没把它做成通用工具三层天花板这个项目注定走不到“实用”阶段因为它撞上了三层天花板。第一层是状态存储的物理体积内存和寄存器全部要用 checkbox 实现规模无法承载任何真实程序第二层是规则组合爆炸每条新增指令意味着成百上千条 CSS 规则工程量不可持续第三层是性能天花板浏览器样式计算不是为高速状态切换设计的时钟频率上不去。这三层天花板放在一起决定了 x86CSS 只能停留在 demo 和教学演示层面。如果你真想模拟 x86 程序老老实实用 JS 或 WASM。说实话我见过不少新手看完这类项目后误以为“CSS 无所不能”结果把业务逻辑往 CSS 里堆最后页面一打开就卡死这是本末倒置。炫技归炫技工程是工程两者要分得很清。5.2 这个实验给前端开发者的三条现实启发虽然 x86CSS 本身不能用于生产但它给我的前端思维方式带来了不少冲击。第一不要低估 CSS 的状态表达力。很多原本习惯用 JS 维护的状态其实可以用 CSS 选择器和:checked很好表达比如手风琴菜单、纯 CSS 开关、表单步骤条这些场景用 checkbox hack 能显著减少 JS 体积。第二选择器匹配成本是真实存在的性能瓶颈。x86CSS 让我直观感受到“选择器越多、DOM 越大样式计算越贵”。日常开发里我们写 CSS 时很少考虑匹配次数但大项目里的通配符选择器、深层级选择器真的是在消耗浏览器性能。这个项目就是一份活教材。第三真实世界是“多语言协作”的。x86CSS 证明了 CSS 能计算但证明了“能计算”不等于“应该计算”。正确的姿势是让每种语言做自己最擅长的事HTML 管结构CSS 管样式JS 管交互和逻辑。交叉使用能带来创意滥用只会带来维护噩梦。5.3 如果你也想复刻一个“纯 CSS 状态机”从哪入手我自己看完 x86CSS 后手痒做了一个简化版“纯 CSS 半加器”从零到跑通用了不到半天。如果你想亲身体验这种实现的奥妙我强烈建议按这个顺序推进别一上来就啃 x86CSS 的完整源码那是找虐。第一步先做一个单 bit 的半加器。弄两个 checkbox 表示 A 和 B再用选择器实现 XOR 和 AND 两个输出给输出接两个小方块的颜色变化。跑通后你就算入门 checkbox hack 了。第二步把半加器扩展成 4 位加法器。核心难点是处理进位链——低位的进位要参与高位的运算。在 CSS 里进位本质是另外一组 checkbox你要手动控制它们的开关顺序。这一步能让你彻底理解“CSS 模拟电路”的笨拙和优雅。第三步做一个“两状态”的状态机。用两个 checkbox 表示当前状态通过选择器切换不同区域的显示模拟一条最简单指令的执行流程。到这里你就拥有了 x86CSS 的最小内核骨架。再往后加寄存器、加内存、加指令分支都是在这个骨架上添砖加瓦。我踩过的一个坑是中间想偷懒用~通用兄弟选择器乱匹配结果状态一多就开始串扰几个复选框互相影响调试到怀疑人生。强烈建议在 HTML 结构里做严格的分区把“存储区”“逻辑区”“输出区”的 DOM 层级固定下来每类选择器只在固定区域内匹配否则整个状态机根本没法维护。说句实在话x86CSS 这类项目属于“看完膝盖发软、日常开发绝不会用”的类型但它给我最大的收获是理解了状态机、逻辑门和图灵完备这些抽象概念之后再回头看 JS 模拟器、虚拟机、编译器的设计会突然觉得豁然开朗。CSS 这个看似最“肤浅”的前端语言反倒成了我理解计算机底层原理的一扇暗门。如果你也重新对汇编和 CPU 产生兴趣建议找一个 JS 写的 8086 模拟器配合它一起玩一个负责看懂原理一个负责看清结构搭配起来效果最好。