前几天我做了一个 OpenWrt 的 LuCI 插件江西师大校园网，它的目标很直接：把江西师范大学校园网的 SRun 认证流程搬到路由器上，让登录、保活、定时上下线这些事情自动完成，而不是每天手动切换设备折腾。
项目目标
这个项目一开始的目标其实很朴素：
- 在 OpenWrt 上实现校园网自动认证
- 提供 LuCI 页面，方便直接在网页里配置账号密码
- 支持查看在线状态和手动立即登录
- 支持定时上下线
- 在特定时段自动切换到手机热点，恢复后再切回校园网
- 最终能直接通过 GitHub Actions 构建出
.ipk，方便安装
也就是说，项目从一开始就不是“先写脚本再说”，而是直接按“可安装、可配置、可运行”的插件形态去做的。
一些思路
如果只是写一个校园网登录脚本，其实不难，难的是把它做成一个“能长期跑”的 OpenWrt 插件。
因为一旦上了路由器，问题就不只是“能不能登录”了，还包括：
- OpenWrt 环境里 Python 依赖是否稳定
- 后台脚本是否能长期运行
- 网络断开时如何恢复
- LuCI 配置和后台逻辑怎么对齐
- 打包流程能不能复现
- 别人能不能方便地安装
所以这个项目后面的很多提交，实际上都在解决“工程化”问题，而不是单纯补功能。
踩坑记录
有一个很关键的提交是 Minor Update for http request error。这说明最开始的认证请求并没有稳定到“一把过”。
后来的处理方式很实用：
- 优先尝试
urllib - 失败后再退回到系统命令行工具
- 同时兼容
wget和uclient-fetch - 请求失败时把不同来源的错误信息都收集起来
这个坑让我意识到，OpenWrt 上“请求能发出去”和“请求逻辑写对了”是两回事。
桌面环境里理所当然的东西，到了路由器上可能就得准备多套 fallback。
体会
这个项目最开始看起来像是一个“小插件”，但真正做起来，问题远比“写登录脚本”复杂。
- 路由器环境比本地开发环境更脆弱
- 网络状态本身就不稳定
- 前端配置和后台行为必须一致
- 自动化构建要考虑依赖、缓存和目录注入
- 很多 bug 都不是“写错了”，而是你自己定了一个错误预设
换句话说，这个项目让我更明显地意识到：
能跑只是第一步，稳定、可配、可构建、可维护，才是一个插件真正麻烦的地方。
这篇记录主要是想把这个项目做下来的过程留个痕迹。对我来说，这种开发过程本身就挺值得记下来。
