性能优化的本质：把资源堆在用户最在意的地方

这篇文章来自最近和几位做游戏开发的朋友的交流，他们分享了一些实际项目里的思考，我尝试把这些观点整理一下，以便于自己学习和思考。

业务理解才是性能优化的起点

很多人谈性能优化，上来就是 profiling 工具、火焰图、bottleneck 分析。这些都对，但在此之前有一个更根本的问题没有被回答：用户到底在意什么？

所谓业务理解，核心只有一件事：知道用户在哪些入口上使用频率最高，对哪些实体的感知最明显。

这个判断一旦确立，性能优化的资源分配策略就清晰了：

• 用户感知强的地方：集中资源，做到极致
• 用户感知弱的地方：降级处理，时间换空间，甚至直接做成背景素材

这不是偷懒，这是正确的工程决策。

粒子效果：AI 搞不定的典型问题

游戏性能优化里有一类问题是 AI 至今无法端到端解决的，粒子效果就是典型。

原因不复杂：粒子效果是低频的、弥散的、时间维度上的视觉信息。你很难用文本精确描述「这个地方的粒子效果感觉不够有冲击力」——因为这个判断本身是主观的、动态的、情绪化的。

AI 在图像处理上擅长高频信息——边缘、纹理、轮廓。粒子效果偏偏不是这类信息，它更接近人对「氛围」和「手感」的感知，这类感知在训练数据里极难被标注和量化。

所以粒子效果的优化，本质上依赖的是工程师的眼睛和经验，而不是工具。

这也是性能优化方向长期有壁垒的原因之一：它的核心竞争力是人类感知能力的延伸，不是信息处理问题。

大型游戏的混合存储架构

游戏客户端的存储设计是一个很好的架构思维训练场，因为它几乎囊括了所有存储场景的权衡。

本地存储与远程存储同时存在

主要用户数据必须存在服务器上，原因有两个：联机同步和防止作弊。但并非所有数据都需要走网络——高频读取的轻量配置完全可以存在本地，省掉不必要的网络请求和数据库查询。

客户端本地存储的主流方案：

• SQLite：嵌入式关系型数据库，移动端和桌面端的标配，适合结构化的本地数据
• DuckDB：列存储，OLAP 向，适合本地数据分析场景，近年来在 WASM 方向很活跃

为什么游戏行业大量使用 MongoDB

游戏有一个其他行业少见的特点：运营活动频繁，且每次活动几乎都会破坏现有的数据结构。

春节活动要新增灯笼积分字段，周年庆要新增限定皮肤字段，活动结束这些字段又要清理。如果用关系型数据库，每次都要 ALTER TABLE，风险极高，上线成本极大。

MongoDB 的 schema-free 特性天然适合这个场景——字段的增删不需要改表结构，直接在文档层面操作。这不是 MongoDB 设计之初的偶然，官方教程里明确提到 JSON 类型字段的设计初衷就包含游戏行业的需求。

一个典型的大型游戏存储架构

数据类型	存储方案	原因
用户账号/支付	MySQL/PG	强一致性、事务
角色属性/背包	MongoDB	字段灵活、嵌套结构
排行榜/计数器	Redis	高频读写、实时性
聊天记录	Kafka+ES	流式处理、全文检索
本地配置	SQLite	离线、低延迟
行为日志/埋点	ClickHouse	OLAP 分析

没有最好的数据库，只有最适合这个场景的数据库。架构能力的核心，就是知道在哪个节点用哪把刀。

AI 的复杂度天花板

AI 辅助开发已经是事实，但有一个边界需要清晰认知：当问题的复杂度超过某个阈值，AI 就无法端到端完成了。

举两个极端的例子：

• 新思（Synopsys）的 IC 仿真器：几十年工程积累，涉及电路理论、数值计算、硬件行为建模，每一个细节都是前人趟过的坑
• 兼容市场主流 APP 的操作系统：兼容性问题本身就是无数 corner case 的集合，没有穷举完的可能

这类问题有一个共同特点：前面没有现成的路，需要人来开路。

AI 是在已有路径的概率分布上做预测，它天然是个保守主义者。你提供一个它不熟悉的新范式，它会本能地往高概率路径拉，因为那是它的舒适区。底层开拓者的价值恰恰在这里——他们靠第一性原理推导，不是经验复用，而 AI 在这里完全失语。

所以 AI 时代真正稳固的技术方向是什么？

• 复杂度极高、corner case 极多的底层工程
• 依赖主观判断和审美的优化工作
• 需要跨层系统性视角的架构设计

确定性任务的价值已经被 AI 清零。剩下有价值的，全是不确定性。而处理不确定性的能力，恰恰是最难培养的。