性能与陷阱

PuXian 的性能问题几乎都能归到一句话：你在解释轨还是编译轨。搞清这一点，剩下的坑都是有解的。

实测：同一个循环，解释轨比编译轨慢约 500 倍

var t0 = now_ms()
var sum = 0
for i in range(0, 100000):
    sum += i
print("耗时 " + str(now_ms() - t0) + " ms")

坑一：逐像素绘图

gfx.set_px 内部是 c[2][y*w+x] = color：嵌套下标赋值每次都把内层列表复制一份再写回。132×44 的画布写 6400 次，解释轨实测 3.85 秒；同样的写入直接作用在 canvas_pixels(c) 取出的列表上只要 0.89 秒；编译轨（含 --fast）4 ms。

坑二：bytes 是不可变的

var b = bytes("abc")
var c = bytes_set(b, 0, 65)   # 返回值是新对象
print(bytes_to_str(b))
print(bytes_to_str(c))

abc
Abc

忘记接返回值，看起来"改了但没生效"。逐字节修改还有性能问题：每次 bytes_set 都复制一份，几十万次就是几秒。做法是攒成列表最后一次性拼。

坑三：大块写入会挂

坑四：字符串操作对二进制不安全

split、replace 这类字符串函数遇到 NUL 字节会截断。40 MB 的 zip 用 split 处理，实测被切成 108 个字符。二进制一律用 bytes_* 族。

坑五：除法返回浮点

var avg = 7 / 2
print(str(avg))
print(str(int(avg)))

3.5
3

要整数用 //；位运算（>> &）只吃 int，浮点会报错。

坑六：保留字撞车

坑七：json_parse 会终止程序

var v = json_parse("坏输入")    # 不可捕获，进程直接挂

一律 json_parse_opt。同理 int("abc")、hex_to_bytes 的畸形输入。处理外部数据前先校验。

坑八：print 就是 HTTP 响应

在 Ma 的 px_routes 里，print 写的是标准输出 = 响应体。处理中间打一行日志，客户端收到的是坏响应。日志走 /dev/stderr。

坑九：mode: auto 的首请求

Ma 的 px_routes 在 mode: auto 下，首次请求走解释轨（可能要 1 秒多），之后才用编译产物。用户感知是"第一次点特别慢"。对交互敏感的路由直接写 mode: fast。

性能优化清单