先说结论

Nuitka 默认模式（standalone / onefile）下，模块常量表、字符串、函数名、docstring 大都以明文或简单编码形式留在二进制里。它不是加密，只是混淆。真正做加密的方案，通常是在其外面再包一层 loader。

判断顺序：先看有没有壳，再看常量表能不能直接提取，最后才考虑动态调试。顺序反了会浪费大量时间。

文件头里藏着什么

把 .pyd 拖进十六进制编辑器，前 2 字节是 MZ，标准 PE。真正的信息在 .rdata 段。

import pefile

pe = pefile.PE("module.pyd")
for sec in pe.sections:
    name = sec.Name.rstrip(b"\x00").decode(errors="replace")
    print(f"{name:10} vaddr={sec.VirtualAddress:#x} "
          f"rawsize={sec.SizeOfRawData:#x}")

重点看 .rdata 和 .data 的大小比例。如果 .rdata 异常大（几 MB），基本可以确定常量都堆在那儿。

关于 IV 与密钥

如果 loader 用了 AES，密钥和 IV 通常会以两种形式出现：

• 硬编码在 .rdata，长度刚好 32 / 16 字节
• 由某个常量字符串经过一次哈希派生

后者更难找，但特征也明显——一定会引用 SHA-256 或 MD5 的常量表。

三种方案的对比

下一步做什么

静态能看到的东西有限。真正跑起来之后，用调试器在 PyImport_ExecCodeModule 下断点，能直接拿到解码后的 code object——这比在二进制里翻字符串高效得多。

整个过程我保持在本地、离线、只针对有授权的样本。这一点没有讨论空间。

第一步：把 JSON 去掉

每帧的字段名完全可以省略。约定一个固定顺序，用数组代替对象：

// 之前：每帧 240 字节
{ "players": [{ "id": "a1", "x": 12, "y": 33, "len": 7 }] }

// 之后：每帧 14 字节
[1, 12, 33, 7]

字段名在协议里只出现一次，之后都是位置约定。这一项直接砍掉 90% 的体积。

第二步：只发变化

全量推送没有必要。客户端保留上一帧，服务端只发 diff：

def diff(prev, cur):
    out = []
    for pid, obj in cur.items():
        if prev.get(pid) != obj:
            out.append(pack(pid, obj))
    return out

安静的时候，一帧就是几个字节。热闹的时候才会涨，但热闹的时候用户注意力也在别处，掉几帧没人会发现。

第三步：二进制 + base64

SSE 是文本协议，二进制要先转 base64。看起来会膨胀 33%，但因为前面已经砍掉了 90%，最终结果仍然远小于原始 JSON。

只要协议是你自己定的，压缩永远有空间。真正的成本不在带宽，在于你愿不愿意写一个自定义的编解码器。

客户端插值

服务端 20fps，屏幕 60fps，中间的空档靠客户端补。简单线性插值加一点缓动，肉眼完全看不出差别，但服务端压力降到三分之一。

const t = (now - lastFrameAt) / FRAME_MS;
render(lerp(prevState, nextState, Math.min(t, 1)));

整个方案跑在两核机器上，CPU 常年在 8% 以下。省下来的不是钱，是那种"够用"的踏实感。

WAL 之后，读写不互斥

默认的 journal 模式下，写会锁住整个库。打开 WAL 之后，读写可以并行，单进程写入也能达到每秒几千次事务。

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA cache_size = -32000;

这三行基本就是全部调优。第二条在断电时可能丢最后一个事务，但对博客来说完全可接受。

备份是一个 cp

这是我坚持用它的真正原因。MySQL 的备份要考虑锁、一致性、binlog 位置；SQLite 只需要：

sqlite3 app.db ".backup /root/backup-$(date +%F).db"

或者干脆停两秒服务，直接 cp。恢复也是复制回去。没有第二个步骤。

什么时候不该用它

• 需要多台机器同时写（它没有主从）
• 单表上千万行且频繁范围扫描
• 需要细粒度的权限控制

这三条之外的绝大多数场景，SQLite 都不会成为瓶颈。真正的瓶颈通常是你自己的查询写得不对。

写代码的时候它表现为重构上瘾：功能已经能跑了，但你觉得这个抽象不够干净，于是推倒重来，第三天发现新的抽象也有问题。

选工具的时候它表现为选型焦虑：为了一个日均访问几十次的小站，比较了六个框架，读了二十篇 benchmark，最后选了最复杂的那个，因为"以后可能会用到"。

以后大概率不会用到。而后来的你，只会为当初多出来的复杂度付维护成本。

判断标准其实很简单

问自己一句：这个"更好"，半年后还有人能感觉到吗？

如果答案是不能，那它就不值得。半年后能感觉到的，通常是启动速度、故障恢复、以及"这东西居然一直没坏"的安心感——这些恰恰是简单方案更容易给出的。

所以我现在写东西的顺序变了：先让它跑起来，再让它不坏，最后才考虑好看。大多数项目停在第一步就已经交付了价值。

凌晨不一样。没有人会在这个时候找你，所有未读都安静下来。屏幕的光照着桌面，风扇声音很低，你能听见自己思考的过程。

我不是鼓励熬夜。我只是觉得，每个人都需要一段不被打断的时间，用来处理那些白天排不进日程的事情——比如想清楚一个设计，比如承认某个方向是错的。

有些决定只能在安静的时候做出来。热闹的时候，人只会顺着惯性往前走。

所以我把重要的判断都留到晚上。白天只负责执行。