这个开发者用3个披萨切片，把Canvas干出了游戏圈

一个教育类数学游戏，页面加载时间从2.3秒压到0.4秒，体积从1.2MB缩到47KB。开发者Sean在7x.games上的这个案例，给所有迷信"游戏必须用游戏引擎"的人上了一课。

披萨切片里的三角函数

分数教学最直观的可视化是什么？一个圆饼切成几块，几块涂色。Sean的Fraction Math Master需要动态生成任意分母的圆饼图——分母3就是3等分，分母8就是8等分，分子决定涂几块。

常规思路：预制一堆PNG，或者上Canvas绘图。Sean选了第三条路：纯SVG路径，实时计算。

核心代码不到20行。以圆心为原点，用(2 * Math.PI) / denominator算出每块角度，Math.cos和Math.sin定位弧边端点，拼成SVG的path指令。没有图片请求，没有位图缩放模糊，文件体积按字节算。

更妙的是交互层。答对时加一道transform: scale(1.03)的CSS动画，SVG的DOM属性让这种"弹一下"的反馈比Canvas重绘轻量得多。移动端缩放也毫无锯齿——矢量图的本质优势。

那个差点让浏览器崩溃的while循环

游戏需要生成干扰项。简单模式里，分母上限是6，正确答案可能是1/2。开发者最初的写法很直觉：随机生成分数，撞车正确答案就重新随机，直到凑够3个干扰项。

陷阱在这里：当数学约束收紧，可选的"错误答案"池子可能比需要的数量还少。while循环找不到新数，永远转下去，标签页直接卡死。

Sean's fix彻底换了思路——预生成池子。写死双重循环，遍历所有可能的分子分母组合，过滤掉正确答案，一次性扔进数组，洗牌，取前3个。从"猜谜式随机"变成"确定性枚举"，时间复杂度从O(∞)降到O(n²)，且绝对终止。

这段代码现在看起来理所当然，但调试无限循环的那个下午，浏览器的崩溃日志大概不太美好。

游戏为什么要做SEO？

7x.games是个网页游戏站，流量来自搜索。Sean在Fraction Math Master里塞了一套JSON-LD结构化数据，标记这是"教育游戏"、适合"3-5年级数学"。

Google的富媒体结果能直接显示游戏类型和难度，点击率比纯链接高出一截。这是纯SVG方案的隐藏收益：Canvas内容对爬虫是黑盒，SVG的DOM结构天生可被索引。

Next.js的静态导出（Static Export）把每个游戏页面预渲染成HTML，CDN直出，首屏时间压进半秒。作为对比，一个引了Phaser引擎的同类项目，光是引擎体积就200KB+。

技术选型的减法逻辑

Sean的决策链条很清晰：教育游戏不需要60fps的粒子特效，不需要物理引擎，不需要瓦片地图。需求被过度满足，就是浪费。

他用React状态管理游戏逻辑，Tailwind处理布局，SVG负责所有图形渲染。三件套都是浏览器原生支持，没有加载阻塞，没有运行时编译。

这个案例的讽刺之处在于：游戏开发社区花了十年把引擎越做越重，而一个简单的数学游戏，用1999年就定稿的SVG 1.0规范就能跑得飞起。

Sean在文末留了个钩子——他正在把这套SVG生成逻辑抽象成通用组件，支持饼图、环形进度条、甚至简单的数据可视化。如果这套"轻量图形"的思路能复用到更多场景，Canvas和WebGL的统治地位会不会出现裂缝？