Redis禁止在Lua脚本中非确定性命令（如TIME）后执行写命令，以保证主从一致性；解法一是客户端传入时间戳，二是启用redis.replicate_commands()（仅限单机/主从且≥3.2版本）。
直接结论：这不是“设置Lua脚本只读模式”，而是Redis对脚本执行确定性的强制要求——只要脚本里调用了TIME、RANDOMKEY这类非确定性命令，后续就不能再执行SET、INCR等写命令。根本解法是避免在脚本中调用非确定性命令，或显式启用单命令复制模式。
为什么redis.call('TIME')之后不能redis.call('SET')
Redis 要求 Lua 脚本必须是纯函数：相同输入 → 相同输出 + 相同写入行为。而TIME每次返回不同值（秒+微秒），属于非确定性命令。一旦脚本执行了它，Redis 就认为整个执行路径不可预测，为保证主从数据一致，会拒绝后续所有写命令，报错：Write commands not allowed after non deterministic commands。
常见误判是以为这是权限问题或配置问题，其实和CONFIG SET readonly yes完全无关——这是脚本执行模型层面的硬约束。
- 非确定性命令包括：
TIME、RANDOMKEY、SRANDMEMBER、MONITOR等 - 写命令包括：
SET、INCR、HSET、DEL、EXPIRE等（即带REDIS_CMD_WRITE属性的命令） - 读命令如
GET、HGETALL不触发该限制，但也不能“挽救”已被污染的确定性上下文
两种可行解法及适用场景
你不能绕过这个限制，只能选一种策略适配业务逻辑：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
方案一（推荐）：外部传入时间戳，彻底避开
TIME
把当前时间由客户端计算后作为参数传入脚本，例如：EVAL "redis.call('SET', KEYS[1], ARGV[1]);" 1 mykey 1748392740。这样脚本全程无非确定性调用，无需额外处理，兼容集群、主从、AOF/RDB 全流程。 -
方案二：加
redis.replicate_commands()开启单命令复制
仅适用于单机或主从架构（不适用于 Redis Cluster），且需确认你的 Redis 版本 ≥ 3.2。脚本开头第一行必须是：redis.replicate_commands()，之后才能混用TIME和SET。注意：此时 AOF 记录的是实际执行的 MULTI/EXEC 命令，而非脚本本身，主从同步行为发生改变。
别在集群环境用方案二——redis.replicate_commands() 在 Redis Cluster 下无效，仍会报错。
容易踩的坑：你以为的“只读”不是 Redis 所说的“只读”
READONLY 命令是客户端连接级别的只读标识，只影响该连接后续是否允许发写命令，和 Lua 脚本执行时的确定性校验毫无关系。同样，CONFIG SET slave-read-only yes 或 replica-read-only yes 控制的是从节点是否接受写请求，也不影响脚本内命令顺序检查。
真正关键的分水岭是：脚本里有没有先调用非确定性命令。哪怕你用redis.call('GET', 'x')读完再写，只要中间没夹TIME之类，就完全安全；反之，哪怕只读一次TIME，后面所有写操作都会被拦下。
最隐蔽的坑是间接调用——比如封装了一个工具函数，内部偷偷调了redis.call('TIME')，你在主逻辑里根本没意识到它污染了上下文。
