尧图网页设计 
登录验证码处理辅助工具如何上手mirai-login-solver-sakura 目录、入口与配置全解析【免费下载链接】mirai-login-solver-sakura项目地址: https://gitcode.com/gh_mirrors/mi/mirai-login-solver-sakuramirai-login-solver-sakura 是一套面向 mirai 机器人框架的登录验证码处理辅助工具它的核心价值是把滑块验证、短信验证、设备锁验证等麻烦的登录流程从卡死在终端变成弹个窗口点几下甚至交给手机 App 扫码完成。本文不按传统教程平铺而是从它到底怎么帮你讲起逆向带你拆懂它的代码结构、启动入口和配置开关。一、先看它解决了什么痛点用 mirai 登录 QQ 机器人账号时腾讯会不定期抛各种安全验证滑块验证码、图片验证码、短信验证、设备锁。这些验证码大多要人肉处理默认终端模式下很难操作。mirai-login-solver-sakura 的思路是——它只负责验证过程中的数据传递把验证请求转成可视化窗口或二维码让人方便地完成验证再把结果交还给 mirai。它的能力矩阵在 README 里写得很清楚验证类型支持情况滑块验证Slider✅ 支持可扫码或内嵌 TxCaptchaHelper图片验证码Pic 4code✅ 支持短信验证SMS✅ 支持设备锁验证✅ 支持扫码登录仅用扫码简化交互流程非纯扫码登录跑起来之后你会看到这样的处理界面——滑块验证会弹出窗口提示你用配套 App 扫码遇到设备锁/安全认证时则会列出短信验证设备锁验证等选项你选一个即可一句话总结它的运行形态桌面端mirai-console 插件负责把验证转成二维码/窗口手机端配套 Android App负责扫码和操作两端通过内网 HTTP Socks 隧道互通。二、逆向拆解从运行形态反推目录结构理解了双端协作的形态再看目录就豁然开朗。仓库根目录下只躺着两个真正的源码模块settings.gradle ← 模块注册表 gradle.properties ← 版本号等公共属性 mirai-login-solver-sakura/ ← 核心模块桌面端逻辑Kotlin android/ ← 配套 App 模块Android/Kotlin ci-helper/ ← 构建辅助工具Java一般不用动2.1 核心模块内的分工地图真正需要重点关注的是mirai-login-solver-sakura/src/main/kotlin/下的几个包它们按职责清晰分层路径职责对应功能console/ConsolePluginMain.kt插件总入口启动服务器、按环境选择 LoginSolverresolver/SakuraLoginSolver.kt桌面 GUI 处理器弹窗处理各类验证码resolver/CommonTerminalLoginSolver.kt终端降级方案无桌面时用命令行交互resolver/JLineLoginSolver.kt终端增强方案无桌面且支持 JLine 时的交互resolver/MZDTxCaptchaHelper.kt旧版辅助器兼容内嵌 TxCaptchaHelper 处理滑块slovbroadcast/SakuraTransmitDaemon.kt数据中转服务器HTTP 服务 Socks 隧道二维码请求分发slovbroadcast/DefaultSettings.kt配置读取中心集中读取所有 JVM 参数ProjMetadata.kt版本元数据从metadata.properties读取版本/commit其中SakuraTransmitDaemon是全项目的神经中枢——它启动了用于数据交换的 HTTP 服务器把验证请求包装成二维码里的 JSONApp 扫码后通过内网 IP 回传验证结果。协议细节在 README 的数据交换一节有完整 JSON 示例对接自己客户端的开发者可以从这里入手。2.2 两个模块怎么被组装起来settings.gradle只做了一件事声明模块存在。rootProject.name mirai-login-solver-sakura include :mirai-login-solver-sakura include :ci-helper也就是说android/目录在 Gradle 根工程里其实没有注册它由 CI 流程单独构建出apk-release.apk。想要本地只跑核心模块执行核心模块下的构建任务即可想完整构建两端的产物则按 CI 的流程分别处理。三、手把手看懂启动入口从一行 Kotlin 到弹出窗口整个程序真正被 mirai-console 加载的地方只有一个console/ConsolePluginMain.kt中的ConsolePluginMain对象。它是标准 mirai-console 插件的写法关键逻辑浓缩在onLoad()里三步走// 1. 启动数据中转服务器HTTP Socks 隧道 val server SakuraTransmitDaemon(...) server.bootServer() // 2. 判断当前是否有图形桌面环境 val noDesktop System.getProperty(mirai.no-desktop) ! null || GraphicsEnvironment.isHeadless() // 3. 按环境挑选不同的验证处理器 val solver if (noDesktop) { JLineLoginSolver(server) // 服务器/无桌面 → 命令行交互 } else { SakuraLoginSolver(server) // 有桌面 → 弹窗交互 }这段代码揭示了两个关键设计自动降级云服务器没有图形界面程序会自动切到JLineLoginSolver或CommonTerminalLoginSolver靠终端输入完成验证不需要改代码。挂钩时机通过contributeBotConfigurationAlterer把选中的solver塞进每个 Bot 的登录配置里mirai 登录遇到验证时就会回调这个对象。再看桌面端的主角resolver/SakuraLoginSolver.kt。它继承 mirai 的LoginSolver核心是重写几个回调方法override suspend fun onSolveSliderCaptcha(bot: Bot, url: String): String? { // 弹出滑块验证窗口可选“内嵌旧版 Helper”或“生成二维码给 App 扫” } override suspend fun onSolveDeviceVerification(bot, requests): DeviceVerificationResult { // 弹出“短信验证 / 设备锁验证”选择窗口 } override fun createQRCodeLoginListener(bot: Bot): QRCodeLoginListener { // 弹出二维码登录窗口监听扫码状态 }每种验证类型对应一个openWindowCommon弹窗窗口内通过daemon.newRequest(...)创建验证请求再把请求渲染成二维码等待 App 回传结果。整条链路mirai 报验证 → Solver 弹窗 → 生成二维码 → App 扫码 → 服务器回传结果 → 登录继续。四、一键读懂配置文件所有开关都是 JVM 参数这个项目没有传统意义的配置文件所有行为都由JVM 启动参数控制集中读取逻辑在slovbroadcast/DefaultSettings.ktinternal val noTunnel: Boolean by lazy { sysProp(mlss.no-tunnel, false) } internal val serverPort: Int by lazy { sysProp(mlss.port, 0) } internal val tunnelLimited: Boolean by lazy { sysProp(mlss.tunnel.limited, true) }DefaultSettings就像配置中心它从System.getProperty里取值SakuraTransmitDaemon在启动时引用这些值。完整的参数表如下改动后重启插件即生效JVM 参数默认值取值作用-Dmlss.no-tunneltruefalsetrue/false关闭 Socks 隧道功能-Dmlss.port808000-65536指定后端服务端口-Dmlss.tunnel.limitedtruetruetrue/false是否启用隧道安全策略-Dmirai.no-desktoptrue无任意值存在即生效强制使用命令行模式端口有个贴心设计mlss.port设为0默认时程序会先尝试绑定 22333 端口被占用才改用随机端口。这样云服务器只要放行一次 22333 就行避免每次随机端口都要改防火墙——源码里bootServer()那段ServerSocket().use { socket - socket.bind(...) }就是干这件事的。此外版本信息藏在两处根目录gradle.properties里proj.projver0.0.12是核心模块版本号extres/.../metadata.properties是构建期元数据。改版本号时这两个地方要一起留意。五、常见坑点提醒围绕这个项目读者最常踩的三个坑提前给你排雷扫码后崩溃大概率是 Android WebView 版本过旧去系统里更新 WebView 即可。服务器报 No any server availalbe云服务器多半是防火墙没放行 22333 端口局域网环境则检查路由器的 AP 隔离可以先在本机 ping 自己的 IP 刷新路由表。手机和电脑不在同一内网二维码里的server字段是内网 IP 列表App 扫码后靠内网直连回传结果所以手机必须与桌面端连同一个网络。六、下一步建议想深入源码的读者建议按这条线阅读先读console/ConsolePluginMain.kt搞清启动流程 → 再读resolver/SakuraLoginSolver.kt看各验证类型怎么弹窗 → 最后啃slovbroadcast/SakuraTransmitDaemon.kt理解二维码里的 JSON 协议与隧道机制。想对接自己的客户端README数据交换一节就是你的接口文档。克隆仓库后直接跑核心模块的 Gradle 任务配合-Dmirai.no-desktoptrue在无桌面环境也能快速验证效果。【免费下载链接】mirai-login-solver-sakura项目地址: https://gitcode.com/gh_mirrors/mi/mirai-login-solver-sakura创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 登录验证码处理辅助工具如何上手：mirai-login-solver-sakura 目录、入口与配置全解析
登录验证码处理辅助工具如何上手mirai-login-solver-sakura 目录、入口与配置全解析【免费下载链接】mirai-login-solver-sakura项目地址: https://gitcode.com/gh_mirrors/mi/mirai-login-solver-sakuramirai-login-solver-sakura 是一套面向 mirai 机器人框架的登录验证码处理辅助工具它的核心价值是把滑块验证、短信验证、设备锁验证等麻烦的登录流程从卡死在终端变成弹个窗口点几下甚至交给手机 App 扫码完成。本文不按传统教程平铺而是从它到底怎么帮你讲起逆向带你拆懂它的代码结构、启动入口和配置开关。一、先看它解决了什么痛点用 mirai 登录 QQ 机器人账号时腾讯会不定期抛各种安全验证滑块验证码、图片验证码、短信验证、设备锁。这些验证码大多要人肉处理默认终端模式下很难操作。mirai-login-solver-sakura 的思路是——它只负责验证过程中的数据传递把验证请求转成可视化窗口或二维码让人方便地完成验证再把结果交还给 mirai。它的能力矩阵在 README 里写得很清楚验证类型支持情况滑块验证Slider✅ 支持可扫码或内嵌 TxCaptchaHelper图片验证码Pic 4code✅ 支持短信验证SMS✅ 支持设备锁验证✅ 支持扫码登录仅用扫码简化交互流程非纯扫码登录跑起来之后你会看到这样的处理界面——滑块验证会弹出窗口提示你用配套 App 扫码遇到设备锁/安全认证时则会列出短信验证设备锁验证等选项你选一个即可一句话总结它的运行形态桌面端mirai-console 插件负责把验证转成二维码/窗口手机端配套 Android App负责扫码和操作两端通过内网 HTTP Socks 隧道互通。二、逆向拆解从运行形态反推目录结构理解了双端协作的形态再看目录就豁然开朗。仓库根目录下只躺着两个真正的源码模块settings.gradle ← 模块注册表 gradle.properties ← 版本号等公共属性 mirai-login-solver-sakura/ ← 核心模块桌面端逻辑Kotlin android/ ← 配套 App 模块Android/Kotlin ci-helper/ ← 构建辅助工具Java一般不用动2.1 核心模块内的分工地图真正需要重点关注的是mirai-login-solver-sakura/src/main/kotlin/下的几个包它们按职责清晰分层路径职责对应功能console/ConsolePluginMain.kt插件总入口启动服务器、按环境选择 LoginSolverresolver/SakuraLoginSolver.kt桌面 GUI 处理器弹窗处理各类验证码resolver/CommonTerminalLoginSolver.kt终端降级方案无桌面时用命令行交互resolver/JLineLoginSolver.kt终端增强方案无桌面且支持 JLine 时的交互resolver/MZDTxCaptchaHelper.kt旧版辅助器兼容内嵌 TxCaptchaHelper 处理滑块slovbroadcast/SakuraTransmitDaemon.kt数据中转服务器HTTP 服务 Socks 隧道二维码请求分发slovbroadcast/DefaultSettings.kt配置读取中心集中读取所有 JVM 参数ProjMetadata.kt版本元数据从metadata.properties读取版本/commit其中SakuraTransmitDaemon是全项目的神经中枢——它启动了用于数据交换的 HTTP 服务器把验证请求包装成二维码里的 JSONApp 扫码后通过内网 IP 回传验证结果。协议细节在 README 的数据交换一节有完整 JSON 示例对接自己客户端的开发者可以从这里入手。2.2 两个模块怎么被组装起来settings.gradle只做了一件事声明模块存在。rootProject.name mirai-login-solver-sakura include :mirai-login-solver-sakura include :ci-helper也就是说android/目录在 Gradle 根工程里其实没有注册它由 CI 流程单独构建出apk-release.apk。想要本地只跑核心模块执行核心模块下的构建任务即可想完整构建两端的产物则按 CI 的流程分别处理。三、手把手看懂启动入口从一行 Kotlin 到弹出窗口整个程序真正被 mirai-console 加载的地方只有一个console/ConsolePluginMain.kt中的ConsolePluginMain对象。它是标准 mirai-console 插件的写法关键逻辑浓缩在onLoad()里三步走// 1. 启动数据中转服务器HTTP Socks 隧道 val server SakuraTransmitDaemon(...) server.bootServer() // 2. 判断当前是否有图形桌面环境 val noDesktop System.getProperty(mirai.no-desktop) ! null || GraphicsEnvironment.isHeadless() // 3. 按环境挑选不同的验证处理器 val solver if (noDesktop) { JLineLoginSolver(server) // 服务器/无桌面 → 命令行交互 } else { SakuraLoginSolver(server) // 有桌面 → 弹窗交互 }这段代码揭示了两个关键设计自动降级云服务器没有图形界面程序会自动切到JLineLoginSolver或CommonTerminalLoginSolver靠终端输入完成验证不需要改代码。挂钩时机通过contributeBotConfigurationAlterer把选中的solver塞进每个 Bot 的登录配置里mirai 登录遇到验证时就会回调这个对象。再看桌面端的主角resolver/SakuraLoginSolver.kt。它继承 mirai 的LoginSolver核心是重写几个回调方法override suspend fun onSolveSliderCaptcha(bot: Bot, url: String): String? { // 弹出滑块验证窗口可选“内嵌旧版 Helper”或“生成二维码给 App 扫” } override suspend fun onSolveDeviceVerification(bot, requests): DeviceVerificationResult { // 弹出“短信验证 / 设备锁验证”选择窗口 } override fun createQRCodeLoginListener(bot: Bot): QRCodeLoginListener { // 弹出二维码登录窗口监听扫码状态 }每种验证类型对应一个openWindowCommon弹窗窗口内通过daemon.newRequest(...)创建验证请求再把请求渲染成二维码等待 App 回传结果。整条链路mirai 报验证 → Solver 弹窗 → 生成二维码 → App 扫码 → 服务器回传结果 → 登录继续。四、一键读懂配置文件所有开关都是 JVM 参数这个项目没有传统意义的配置文件所有行为都由JVM 启动参数控制集中读取逻辑在slovbroadcast/DefaultSettings.ktinternal val noTunnel: Boolean by lazy { sysProp(mlss.no-tunnel, false) } internal val serverPort: Int by lazy { sysProp(mlss.port, 0) } internal val tunnelLimited: Boolean by lazy { sysProp(mlss.tunnel.limited, true) }DefaultSettings就像配置中心它从System.getProperty里取值SakuraTransmitDaemon在启动时引用这些值。完整的参数表如下改动后重启插件即生效JVM 参数默认值取值作用-Dmlss.no-tunneltruefalsetrue/false关闭 Socks 隧道功能-Dmlss.port808000-65536指定后端服务端口-Dmlss.tunnel.limitedtruetruetrue/false是否启用隧道安全策略-Dmirai.no-desktoptrue无任意值存在即生效强制使用命令行模式端口有个贴心设计mlss.port设为0默认时程序会先尝试绑定 22333 端口被占用才改用随机端口。这样云服务器只要放行一次 22333 就行避免每次随机端口都要改防火墙——源码里bootServer()那段ServerSocket().use { socket - socket.bind(...) }就是干这件事的。此外版本信息藏在两处根目录gradle.properties里proj.projver0.0.12是核心模块版本号extres/.../metadata.properties是构建期元数据。改版本号时这两个地方要一起留意。五、常见坑点提醒围绕这个项目读者最常踩的三个坑提前给你排雷扫码后崩溃大概率是 Android WebView 版本过旧去系统里更新 WebView 即可。服务器报 No any server availalbe云服务器多半是防火墙没放行 22333 端口局域网环境则检查路由器的 AP 隔离可以先在本机 ping 自己的 IP 刷新路由表。手机和电脑不在同一内网二维码里的server字段是内网 IP 列表App 扫码后靠内网直连回传结果所以手机必须与桌面端连同一个网络。六、下一步建议想深入源码的读者建议按这条线阅读先读console/ConsolePluginMain.kt搞清启动流程 → 再读resolver/SakuraLoginSolver.kt看各验证类型怎么弹窗 → 最后啃slovbroadcast/SakuraTransmitDaemon.kt理解二维码里的 JSON 协议与隧道机制。想对接自己的客户端README数据交换一节就是你的接口文档。克隆仓库后直接跑核心模块的 Gradle 任务配合-Dmirai.no-desktoptrue在无桌面环境也能快速验证效果。【免费下载链接】mirai-login-solver-sakura项目地址: https://gitcode.com/gh_mirrors/mi/mirai-login-solver-sakura创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考