技术 on Homo Ludens

限流的实现和问题

Mon, 01 Dec 2025 20:16:00 +0000

限流（Rate Limiting）是服务端的核心防护机制，主要有两种经典策略：令牌桶（Token Bucket） 和 滑动窗口（Sliding Window）。

先来看 Claude 生成的一个交互式演示 HTML，形象地体现出了上述两种方案的区别（推荐使用 Firefox、 Google Chrome 等浏览器查看）：

令牌桶（Token Bucket）

以固定速率往桶里补充令牌；每次请求消耗一枚令牌，桶空则拒绝。允许短时突发（桶满时）。

桶容量 8 补充速率 2/s

当前令牌数

通过请求

拒绝请求

令牌桶（蓝=有令牌，灰=空位）

请求历史 · ●通过 ●拒绝

滑动窗口（Sliding Window）

维护一段时间内的请求记录；窗口随时间向右滑动，超出的旧请求自动丢弃，只统计窗口内的计数。

窗口大小 5s 限额 5

窗口内请求数

通过请求

拒绝请求

滑动窗口（蓝色区域 = 窗口范围）

请求历史 · ●通过 ●拒绝

令牌桶

核心思路：一个有容量上限的桶，系统以固定速率向桶中补充令牌。每次请求到来时取走一枚令牌，桶空则拒绝。

import time
import threading

class TokenBucket:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity        # 桶最大容量
        self.refill_rate = refill_rate  # 每秒补充令牌数
        self.tokens = float(capacity)   # 初始满桶
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        elapsed = now - self.last_refill
        added = elapsed * self.refill_rate
        self.tokens = min(self.capacity, self.tokens + added)
        self.last_refill = now

    def allow(self, cost: int = 1) -> bool:
        with self.lock:
            self._refill()
            if self.tokens >= cost:
                self.tokens -= cost
                return True
            return False

# 使用示例
bucket = TokenBucket(capacity=10, refill_rate=2)  # 桶容量10，每秒补充2个

def handle_request():
    if bucket.allow():
        return "200 OK"
    else:
        return "429 Too Many Requests"

关键特性：允许短时突发——当桶满时连续请求可以瞬间打出 capacity 个，之后降回到 refill_rate 的吞吐速率。适合对突发流量宽容、对长期速率有约束的场景（如 API 限速）。

滑动窗口

核心思路：维护一个时间窗口，记录窗口内每个请求的时间戳。每次新请求到来前，先淘汰所有"已过期"的旧记录，再判断当前窗口内的请求数是否超限。

import time
import collections
import threading

class SlidingWindowLimiter:
    def __init__(self, limit: int, window_seconds: float):
        self.limit = limit
        self.window = window_seconds
        self.timestamps = collections.deque()  # 有序队列存时间戳
        self.lock = threading.Lock()

    def allow(self) -> bool:
        with self.lock:
            now = time.monotonic()
            cutoff = now - self.window

            # 淘汰窗口外的旧请求（队头是最早的）
            while self.timestamps and self.timestamps[0] <= cutoff:
                self.timestamps.popleft()

            if len(self.timestamps) < self.limit:
                self.timestamps.append(now)
                return True
            return False

# 使用示例
limiter = SlidingWindowLimiter(limit=100, window_seconds=60)  # 60秒内最多100次

def handle_request():
    if limiter.allow():
        return "200 OK"
    else:
        return "429 Too Many Requests"

与固定窗口计数器的区别：固定窗口在两个窗口交界处会出现"双倍流量"漏洞（窗口末尾 + 新窗口开头各来一批），滑动窗口通过精确追踪时间戳彻底解决了这个问题。

一些思考

分布式场景下的性能问题

单机内存实现在多实例部署时会失效，需要借助 Redis 做共享状态。

令牌桶用 Redis：用 Lua 脚本保证原子性，避免 TOCTOU 竞争：

-- token_bucket.lua
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local cost = tonumber(ARGV[3])
local now = tonumber(ARGV[4])

local bucket = redis.call('HMGET', key, 'tokens', 'last_refill')
local tokens = tonumber(bucket[1]) or capacity
local last_refill = tonumber(bucket[2]) or now

-- 补充令牌
local elapsed = now - last_refill
tokens = math.min(capacity, tokens + elapsed * refill_rate)

if tokens >= cost then
    tokens = tokens - cost
    redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
    redis.call('EXPIRE', key, 3600)
    return 1  -- 允许
else
    redis.call('HMSET', key, 'last_refill', now)
    return 0  -- 拒绝
end

滑动窗口用 Redis ZSet：利用有序集合天然按时间戳排序的特性：

import redis
import time

r = redis.Redis()

def sliding_window_redis(user_id: str, limit: int, window: int) -> bool:
    key = f"ratelimit:{user_id}"
    now = time.time()
    cutoff = now - window

    pipe = r.pipeline()
    pipe.zremrangebyscore(key, '-inf', cutoff)   # 清理过期
    pipe.zadd(key, {str(now): now})              # 记录当前请求
    pipe.zcard(key)                              # 计数
    pipe.expire(key, window + 1)                 # 设置 TTL
    results = pipe.execute()

    count = results[2]
    if count > limit:
        r.zrem(key, str(now))  # 超限则回滚
        return False
    return True

但是每次请求都需要至少一次 Redis 往返（RTT），在高并发场景下都可能成为瓶颈，两个方案分别可以这样优化：

令牌桶可以一次请求预申请多个令牌：

class BatchTokenBucket:
    def __init__(self, redis_client, key, capacity, refill_rate,
                 prefetch_size=20):
        self.r = redis_client
        self.key = key
        self.capacity = capacity
        self.refill_rate = refill_rate
        self.prefetch_size = prefetch_size   # 一次从 Redis 取多少令牌
        
        self._local_tokens = 0
        self._lock = threading.Lock()
    
    # Lua 脚本：原子地从 Redis 桶里取走 N 个令牌
    LUA_SCRIPT = """
    local key = KEYS[1]
    local capacity = tonumber(ARGV[1])
    local rate = tonumber(ARGV[2])
    local cost = tonumber(ARGV[3])
    local now = tonumber(ARGV[4])
    local data = redis.call('HMGET', key, 'tokens', 'ts')
    local tokens = tonumber(data[1]) or capacity
    local ts = tonumber(data[2]) or now
    tokens = math.min(capacity, tokens + (now - ts) * rate)
    if tokens >= cost then
        tokens = tokens - cost
        redis.call('HMSET', key, 'tokens', tokens, 'ts', now)
        redis.call('EXPIRE', key, 3600)
        return cost
    else
        local available = math.floor(tokens)
        if available > 0 then
            redis.call('HMSET', key, 'tokens', 0, 'ts', now)
            return available
        end
        return 0
    end
    """
    
    def _fetch_tokens(self, amount) -> int:
        """一次从 Redis 取走 amount 个令牌，返回实际取到的数量"""
        script = self.r.register_script(self.LUA_SCRIPT)
        return int(script(keys=[self.key],
                          args=[self.capacity, self.refill_rate,
                                amount, time.time()]))
    
    def allow(self) -> bool:
        with self._lock:
            if self._local_tokens > 0:
                self._local_tokens -= 1
                return True  # 纯本地，无 Redis
            
            # 批量预取
            got = self._fetch_tokens(self.prefetch_size)
            if got > 0:
                self._local_tokens = got - 1
                return True
            return False

也可以把一个大桶拆成多个小桶，每个实例随机打到一个分片，分散写压力，即令牌桶分片：

import random

class ShardedTokenBucket:
    def __init__(self, redis_client, key, capacity, refill_rate, shards=10):
        self.r = redis_client
        self.base_key = key
        self.shards = shards
        # 每个分片分配 capacity/shards 个令牌，速率也均分
        self.shard_capacity = capacity // shards
        self.shard_rate = refill_rate / shards
    
    def allow(self) -> bool:
        shard = random.randint(0, self.shards - 1)
        key = f"{self.base_key}:shard:{shard}"
        # 对单个分片执行 Lua 脚本，分散了 Redis 的写热点
        return self._lua_allow(key, self.shard_capacity, self.shard_rate)

而滑动窗口可以在每个服务实例内存里维护一个本地小窗口，批量向 Redis 预申请配额，而不是每次请求都打 Redis：

import threading
import time

class LocalBatchSlidingWindow:
    def __init__(self, redis_client, key, global_limit, window, 
                 local_quota=50, sync_interval=0.1):
        self.r = redis_client
        self.key = key
        self.global_limit = global_limit
        self.window = window
        self.local_quota = local_quota       # 每次向 Redis 预申请的配额
        self.sync_interval = sync_interval   # 多久同步一次
        
        self._local_remaining = 0            # 本地剩余配额
        self._lock = threading.Lock()
        self._last_sync = 0

    def _fetch_quota_from_redis(self) -> int:
        """向 Redis 申请一批配额，返回实际获得的数量"""
        now = time.time()
        cutoff = now - self.window
        
        pipe = self.r.pipeline()
        pipe.zremrangebyscore(self.key, '-inf', cutoff)
        pipe.zcard(self.key)
        results = pipe.execute()
        current_count = results[1]
        
        available = self.global_limit - current_count
        quota = min(self.local_quota, max(0, available))
        
        if quota > 0:
            # 批量预占：插入 quota 个未来时间戳作为占位符
            batch = {f"_pre_{now}_{i}": now for i in range(quota)}
            self.r.zadd(self.key, batch)
            self.r.expire(self.key, int(self.window) + 1)
        
        return quota

    def allow(self) -> bool:
        with self._lock:
            if self._local_remaining > 0:
                self._local_remaining -= 1
                return True   # 纯内存操作，无 Redis 开销
            
            # 本地配额耗尽，去 Redis 补充
            quota = self._fetch_quota_from_redis()
            if quota > 0:
                self._local_remaining = quota - 1
                return True
            return False

当然，无论用哪种限流策略，都可以在流量进入服务之前就拦截，用 lua-resty-limit-traffic 在 Nginx 里做内存级令牌桶，完全不走应用层和 Redis，延迟降到微秒级：

# nginx.conf
lua_shared_dict my_limit_req_store 100m;  # 共享内存，所有 worker 共用

location /api/ {
    access_by_lua_block {
        local limit_req = require "resty.limit.req"
        local lim = limit_req.new("my_limit_req_store", 2000, 1000)
        -- 2000 req/s，允许 1000 的突发
        local delay, err = lim:incoming(ngx.var.binary_remote_addr, true)
        if not delay then
            if err == "rejected" then
                ngx.exit(429)
            end
        end
    }
    proxy_pass http://backend;
}

那么问题来了。

为什么不直接在 Nginx 侧用 OpenResty 实现令牌桶或滑动窗口限流，而要在后端服务中做呢？

原因有二：

1. Nginx 层访问 Redis 的代价

Nginx 本来是纯内存、零阻塞的热路径。一旦每个请求都要等 Redis，Nginx 的延迟优势就消失了。而且 Nginx 的 cosocket（非阻塞网络）虽然不阻塞 event loop，但连接池管理、错误处理、Redis 超时降级的复杂度全部需要用 Lua 手写，运维成本很高。

这里我个人还在尝试中遇到一个坑，OpenResty 是无法像 Python、Java 等程序一样直接读取环境变量的。所以不想在 nginx.conf 或者 systemd 的配置中明文配置 Redis 口令的话，需要在配置中配置加密后的口令，并配合外部解密脚本使用，非常麻烦。

2. 限流逻辑往往依赖业务语义，Nginx 层拿不到

-- Nginx 能拿到的信息
ngx.var.remote_addr        -- IP
ngx.req.get_headers()      -- HTTP 头
ngx.var.uri                -- 路径

-- 但限流规则经常需要
user_id          -- 需要解析 JWT / Session，Nginx 层做很重
account_tier     -- 需要查数据库（免费用户100次/天，付费用户10000次/天）
api_key_quota    -- 需要关联业务数据
request_cost     -- 不同操作消耗不同令牌数（上传视频 vs 查询列表）

解析 JWT、查用户等级这些事放在 Nginx Lua 里做，实际上是把业务逻辑下沉到了基础设施层，职责严重混乱。

两层限流不是替代关系，而是各司其职。所以工程实践上的共识是：Nginx 做防御性的粗粒度限流（不访问任何外部存储），应用层做业务语义的精细限流（Redis 协调全局状态），两层互补，而不是用一层替代另一层。

鉴权应该在限流前做吗？

一般情况下，不建议把鉴权放在限流之前，顺序通常是：

先做基础限流 → 再做鉴权 → 再做精细限流（按用户）

其原因是鉴权本身有计算成本，而限流的目的之一就是保护这些昂贵操作。

鉴权通常涉及：

解析并验证 JWT 签名（RSA/ECDSA 非对称加密，CPU 密集）
查询 Session Store / Redis
查数据库验证 API Key 是否有效、是否被吊销

如果攻击者用 10 万 QPS 打过来，先做鉴权意味着每个请求都要跑一次 JWT 验证或 Redis 查询，限流反而成了摆设。先限流把绝大多数请求在入口拦截，鉴权只面对漏过来的合法流量。

那问题又来了。

如果攻击者用 10 万 QPS 打过来，那正常用户的请求也会被限流吧？

关键在于让正常用户尽早建立身份。攻击者打的是匿名流量，而已认证的正常用户带着身份，两个配额池完全独立。攻击者把匿名池打满，不影响已登录用户的配额。同时配合分层漏斗、特征识别等手段，而非直接粗暴根据 IP 限流（公司、学校、运营商 NAT 后面可能有成千上万人，共享出口 IP 的正常用户也被拦）。

当攻击规模极大时，识别已经来不及，要在架构层面做隔离。例如大厂（CloudFlare、AWS Shield等）对抗 DDoS 的核心思路就是流量按身份路由到不同集群，把攻击流量和正常流量物理隔离。攻击者打垮匿名集群，登录用户集群以及 API Key 集群（按合同配额）完全不受影响。

避免使用 Python ass 库处理 ASS/SSA 格式的字幕文件

Fri, 25 Apr 2025 14:34:00 +0000

Subtitle Renamer 是我日常使用的字幕重命名工具，非常好的解决了 Jellyfin / mpv 等视频播放软件仅识别与视频文件同名的字幕文件的痛点。

在使用中发现一个问题，经常会出现无法识别 .ass 和 .ssa 格式字幕的问题，而其他格式的字幕（如 .srt ）则从来没有遇到过这种情况。而这些无法识别的字幕，在我所用的所有视频播放软件中都能正常渲染。同时，去仓库的 Issue 中查看，发现已经有人遇到过这个问题。

拉取源码后，找到了报错的代码：

def assSubtitle(file_name):
    # 检测文本编码
    encoding = subEncoding(file_name)

    with open(file_name, "r", encoding=encoding) as file:
        result = ass.parse(file).events

    # 提取正文内容
    subtitle = []
    for item in result:
        # 转义样式中的斜杠
        new_item = item.text.replace("\\", "\\\\")

        # 匹配 {} 之外内容
        ass_pattern = r'\{[^{}]*\}'
        matches = re.sub(ass_pattern, '', new_item)

        # 排除单字的特效字幕
        if len(matches) == 1:
            continue

        # 排除空内容
        if not matches:
            continue

        subtitle.append(matches)

    return subtitle

问题在于 result = ass.parse(file).events 这一行。 ASS/SSA 格式没有一个严格的官方标准，Python 的 ass 库对 .ass 和 .ssa 文件的格式解析比较严格，其本质是一个 parser ，遇到不符合预期的内容就会抛异常，而实际播放器则非常宽容，普遍采取"尽力解析、忽略错误"的策略。

让 AI 总结了以下可能会造成 ass 库报错的场景：

字段数量不匹配 — Dialogue 行的字段数与 Format 行定义的不一致（多了或少了逗号）。播放器会截断或补空，但 parser 直接报错。
编码问题 — 文件实际是 GBK/GB2312/Shift-JIS 但没有 BOM 或声明，库默认按 UTF-8 读取就会炸。播放器通常会自动探测编码。
非标准的 section 或字段 — 比如 [Aegisub Project Garbage]、自定义的 [Fonts]、[Graphics] 等扩展段，以及第一行漏写了 [Script Info] ，或者某些字段名拼写不标准，库不认识就报错。（大部分情况应该属于这种）
Style 定义中的非法值 — 比如颜色值格式不规范（&H00FFFFFF 写成 &HFFFFFF）、布尔值用 True/False 而不是 -1/0、字体大小为空等。
行尾/换行符问题 — 混合的 \r\n 和 \n，或者文件末尾缺少换行。
注释和空行 — 文件中夹杂着 ; 开头的注释或意外的空行，parser 不处理就崩了。

其中第三种情况在各个字幕组制作的字幕文件中非常普遍，毕竟字幕组数量庞大，字幕制作者也可能没有这方面的意识，主打一个“能用就行”。为了兼容这么一部分数量庞大的非标字幕文件，尝试在 ass 报错后尝试使用正则来解析字幕文件：

def assSubtitle(file_name):
    # 检测文本编码
    encoding = subEncoding(file_name)
    try:
        # 原 ass.parse 逻辑
    except Exception as e:
        # 如果ass.parse失败，使用正则表达式解析
        print(f"ass.parse解析失败，使用正则表达式解析: {e}")

        subtitle = []
        try:
            with open(file_name, "r", encoding=encoding) as file:
                in_events_section = False

                for line in file:
                    line = line.strip()

                    # 检查是否进入了[Events]部分
                    if line == "[Events]":
                        in_events_section = True
                        continue

                    # 检查是否进入了其他部分
                    if in_events_section and line.startswith("["):
                        in_events_section = False

                    # 只处理Events部分的Dialogue行
                    if in_events_section and line.startswith("Dialogue:"):
                        # 分割并获取最后一个部分(对话内容)
                        parts = line.split(',', 9)  # 最多分割9次，确保最后一个元素包含全部对话内容

                        if len(parts) >= 10:
                            text = parts[9]

                            # 转义样式中的斜杠
                            text = text.replace("\\", "\\\\")

                            # 移除花括号内的ASS样式代码
                            clean_text = re.sub(r'\{[^{}]*\}', '', text)

                            # 移除多余空白
                            clean_text = clean_text.strip()

                            # 排除单字和空内容
                            if len(clean_text) > 1 and clean_text:
                                subtitle.append(clean_text)
                return subtitle

        except Exception as e:
            print(f"正则解析失败: {e}")
            raise e

搞定。这里保持原来的 ass.parse 逻辑是因为经过实际测试，处理同样的标准字幕文件，使用 ass.parse 比正则解析更快。

Python 中将字符串解析为对象的四种方法

Sat, 17 Aug 2024 12:21:00 +0000

Python 中有四种将字符串解析为对象的方法，除了常见的反序列化工具 json.loads、ujson.loads，还有 eval、ast.literal_eval 两个函数。下表概括了四者的差异：

	`json.loads`	`ujson.loads`	`eval`	`ast.literal_eval`
来源	标准库 `json`	三方库 `ujson`	标准库 `ast`	标准库 `ast`
安全性	安全	安全	不安全	安全
输入	严格 JSON	严格 JSON	任意 Python 语句	Python 字面量
支持类型	JSON 6种类型	JSON 6种类型	全部 Python 类型	str/int/list/dict/tuple/set
单引号字符串	不支持	不支持	支持	支持
性能	中	最快	较慢	较慢

`json.loads` — 标准 JSON 解析

Python 内置 json 模块用纯 Python 实现了一个递归下降 JSON 解析器。CPython 3.x 中核心部分（_json 模块）实际是 C 扩展加速，但逻辑上严格遵循 RFC 8259。

import json

# 基本用法
data = json.loads('{"key": "value", "num": 42, "flag": true}')

# 自定义对象钩子
def parse_decimal(d):
    return {k: float(v) if isinstance(v, str) else v for k, v in d.items()}

data = json.loads('{"price": "3.14"}', object_hook=parse_decimal)

# 严格的格式要求（常见坑）
json.loads("{'key': 'val'}")   # ValueError：单引号不合法
json.loads('{"key": None}')    # ValueError：None 是 Python 不是 JSON（应该是 null）
json.loads('{"key": undefined}')  # undefined 不是有效 JSON

JSON 与 Python 类型映射：

JSON	Python
`object`	`dict`
`array`	`list`
`string`	`str`
`number (int)`	`int`
`number (float)`	`float`
`true/false`	`True/False`
`null`	`None`

注意点：JSON 的 key 必须是双引号字符串；不支持注释；NaN/Infinity 默认不支持（但可通过 parse_constant 兼容）。

`ujson.loads` — 超快速 JSON 解析

ujson（UltraJSON）是用 C 写的第三方 JSON 库，底层直接操作内存、避免了 CPython 对象创建的开销，对大型 JSON 文档比标准库快 2～5 倍。

import ujson

data = ujson.loads('{"key": "value"}')

# API 和 json.loads 基本兼容
ujson.loads('{"ts": 1700000000}')

# 但有细微差异：
ujson.loads('{"val": 1.000000000000001}')  # 浮点精度可能与 json 略有差异
ujson.loads('NaN')    # 部分版本 ujson 会把 NaN 当合法值处理，而 json 会抛异常

注意，ujson 并非 100% 兼容 json 模块；object_hook 等钩子支持不完整；对某些边缘 Unicode 转义的处理历史上有 bug；生产环境建议锁定版本。

实际上 json.loads 在多数场景下性能已经足够，无需额外引入 ujson 增加系统复杂度。

`eval()` — 绝对不要用于外部输入

Python 内置函数，将字符串送入 Python 解释器的代码编译+执行流水线，和直接执行 Python 代码完全等价。

# 能用
eval('{"key": "value"}')   # 返回 dict
eval('[1, 2, 3]')          # 返回 list

# 但不安全
eval("__import__('os').system('rm -rf /')")
eval("open('/etc/passwd').read()")
eval("__import__('subprocess').check_output(['whoami'])")

eval() 对不可信输入的任何使用场景都有替代方案，永远不要用于解析外部数据。

`ast.literal_eval` — 安全的 Python 字面量解析

ast.literal_eval 先用 Python 编译器将字符串解析为 AST（抽象语法树），然后只允许 AST 中出现字面量节点（Constant、List、Dict、Tuple、Set），遇到任何函数调用、名称引用等节点都会抛出 ValueError，不会执行任何代码。

import ast

# 比 json.loads 宽松的地方：支持 Python 语法
ast.literal_eval("{'key': 'value'}")          # ✓ 单引号 OK
ast.literal_eval("[1, 2, 3]")                 # ✓ list
ast.literal_eval("(1, 2, 3)")                 # ✓ tuple（json 不支持）
ast.literal_eval("{1, 2, 3}")                 # ✓ set（json 不支持）
ast.literal_eval("{'a': None, 'b': True}")    # ✓ None/True/False（Python 风格）
ast.literal_eval("3.14")                      # ✓ 数字字面量
ast.literal_eval("b'bytes'")                  # ✓ Python 3 bytes 字面量

# 不支持的
ast.literal_eval("[x for x in range(10)]")   # ValueError：有表达式
ast.literal_eval("1 + 2")                    # ValueError（3.2以后）
ast.literal_eval("os.getcwd()")              # ValueError：有调用

经典的使用场景是解析 Python repr() 的输出，或来自可信内部系统（但非完全受信任）的配置字符串，解析 set/tuple 等 JSON 无法表达的类型。

注意：

对超大嵌套结构（几千层递归）有栈溢出风险（CPython 有递归深度限制），建议在解析前做大小/深度预检。
解析速度比 json.loads 慢 5～10x，不适合高频路径。
Python 3.2 之前 1+2 会返回 3（有一个算术折叠的 bug），之后修复了。
对于大字符串，它实际上会构建完整 AST 再遍历，内存开销比 json 高。

常见混淆场景

import json, ast

# 场景1：Python repr 的 dict（单引号）
s = "{'a': 1, 'b': True}"
json.loads(s)          # JSONDecodeError
ast.literal_eval(s)    # ✓ {'a': 1, 'b': True}

# 场景2：含 tuple 的字符串
s = "(1, 2, 3)"
json.loads(s)          # JSONDecodeError
ast.literal_eval(s)    # ✓ (1, 2, 3)

# 场景3：含 None（JSON 是 null）
json.loads('{"x": null}')    # ✓ {'x': None}
json.loads('{"x": None}')    # JSONDecodeError
ast.literal_eval('{"x": None}')  # ✓ {'x': None}

# 场景4：高性能 JSON
import ujson
ujson.loads('{"a": 1}')  # ✓ 最快

总结

优先用 json.loads ，不能用就 ast.literal_eval ，出现性能瓶颈就上 ujson.loads ，永远不要用 eval 。