运行时模型
JokyMouse 的 Lua 运行时遵循一个很明确的原则：脚本可以自动化输入、读取自身设置、并在关键节点与用户沟通，但平台不会把整套桌面 UI 控制权无限制地开放给脚本。
模块边界
| 模块 | 加载方式 | 负责内容 |
|---|---|---|
| jokymouse | require("jokymouse") | 运行时控制、设置读取、异步任务、鼠标键盘输入 |
| jokymouse.system | require("jokymouse.system") | 系统时间与窗口检索 |
| jokymouse.dialog | require("jokymouse.dialog") | 面向用户的提示框与确认框 |
| jokymouse.log | require("jokymouse.log") | 运行日志与调试输出 |
| jokymouse.ocr | require("jokymouse.ocr") | 屏幕识字与文字读取 |
| jokymouse.screen | require("jokymouse.screen") | 屏幕尺寸、取色与找图 |
| jokymouse.http | require("jokymouse.http") | HTTP 请求（受白名单保护） |
| jokymouse.json | require("jokymouse.json") | JSON 序列化与反序列化 |
中断与正常退出
运行中的脚本可能因为用户手动停止、平台要求终止，或者脚本自身调用 jm.exit(...) 而结束。这三种路径的含义不同：
- 用户或平台主动停止时，运行时会抛出中断错误，脚本应当尽快结束。
- 调用
jm.exit(...)时，整体会被视作正常完成，同时会停止其他 fork 出来的任务。 - 长循环或等待逻辑应该使用
jm.sleep(...)或jm.ensure_running()，这样才能及时响应停止信号。
settings 的角色
脚本的 settings 是发布链路中的正式配置，不只是本地表单。运行时通过 jm.settings() 读取完整配置，平台会把这些值串进创作页、安装页和运行时。
fork 任务模型
jm.fork(fn, ...) 会创建一个异步任务并返回 task_id。随后可以用 jm.wait_task(task_id, timeout_ms?) 轮询结果，或者在不再需要时调用 jm.cancel_task(task_id)。
这种模型适合把主流程和辅助流程拆开，例如：
- 主任务负责切账号。
- 子任务负责定时检查某个 UI 是否出现。
- 任一方决定脚本结束时，由
jm.exit(...)统一收口。
为什么 dialog 是单独模块
提示框与自动化输入是两类职责。把这类交互留在 jokymouse.dialog 里，可以明确告诉脚本作者：
- 这是和用户沟通的正式接口。
- 这是平台愿意持续维护的交互边界。
- 这不等价于任意自定义窗口系统。
接下来可以按需查看 jokymouse API、jokymouse.system API、jokymouse.dialog API、jokymouse.log API、jokymouse.ocr API、jokymouse.screen API、jokymouse.http API 和 jokymouse.json API 的详细签名。