redis lua脚本原生不支持复杂正则匹配，仅提供基础模式匹配（如%d+），不支持d、(?i)、.*?、分组捕获等；禁止动态加载外部库（如lrexlib-pcre）；推荐在客户端处理或使用redisearch的ft.search regex。
Redis Lua脚本原生不支持正则匹配
Redis 内置的 Lua 环境（基于 Lua 5.1）**没有 string.match 的 PCRE 或 POSIX 扩展能力**，仅提供基础的模式匹配（如 %d+、^%w+$），不支持 d、(?i)、.*?、分组捕获后反向引用等常见正则特性。你写的 string.match("abc123", "\d+") 会静默失败或返回 nil —— 因为 Redis 的 Lua 没有启用 lua-pcre 或类似扩展。
无法在 Redis 中动态加载外部 Lua 库
你不能在 EVAL 或 EVALSHA 中执行 require "lrexlib-pcre" 或 package.loadlib：Redis 启动时已锁定 Lua 环境，禁用所有文件 I/O 和动态库加载。任何尝试调用 os.execute、io.open、require（非内置模块）、loadstring（含恶意代码防护）的操作，都会直接报错：Lua redis() command arguments must be strings or integers 或更明确的 ERR Error running script (call to f_...): @user_script:1: module 'lrexlib-pcre' not found。
可行的替代方案只有三种，且各有硬约束
必须接受“复杂正则不在 Redis 端做”这一前提：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在客户端做匹配：把数据
GET或LRANGE出来，用业务语言（Python/Go/Java）的成熟 regex 引擎处理，再决定是否写回 Redis —— 这是**最常用也最安全**的做法； - 用 Redis 6.0+ 的
FT.SEARCH+ RediSearch 模块：它支持WHERE子句中的REGEX（如@field:[a-z]+\d{3}），但需提前建索引，且 regex 语法受 RediSearch 自身限制（不支持 lookaround、递归等）； - 改用近似匹配逻辑：例如用
STRLEN+SUBSTR+STRPOS组合模拟简单查找，或用SCAN配合KEYS模式（如user:*:202[3-5]*）做前缀/通配过滤，再由客户端二次筛选。
强行“注入”正则能力的风险极高
有人试图编译定制版 Redis，静态链接 lrexlib 并开放 require，但这会导致：
- 失去官方升级路径，每次 Redis 小版本更新都需重编译；
- 脚本执行沙箱被破坏，存在远程代码执行（RCE）风险（尤其当 Lua 脚本来源不可控）；
- 性能断崖下跌：PCRE 匹配比 Redis 原生字符串操作慢 1–2 个数量级，且无法利用 Redis 的内存局部性优化。
真正需要复杂正则的场景，说明数据结构或访问模式可能已超出 Redis 的设计边界 —— 这时候该考虑的是换存储，而不是给 Redis “打补丁”。
