易养鸽
生产管理系统
面向鸽场日常生产管理，包含 Web 管理端、Android 作业端和 NFC/RFID 刷卡入口。
技术栈
- Python
- FastAPI
- SQLAlchemy
- MySQL
- Vue 3
- TypeScript
- uni-app
- Docker Compose
01 生产现场
02 管理与作业
我的工作
我从 0 开始完成这套系统的全栈开发，覆盖后端业务规则、Web 管理端和 Android 现场端，把鸽场的日常生产、刷卡作业和管理汇总接在一起。
把生产流程落到数据和接口
围绕笼位、生命周期、蛋窝和幼崽批次组织数据，处理查蛋、抽留、放仔、调仔等操作，以及对应的待办、异常和操作历史。
完成管理端与现场端
管理端提供列表、工作表和统计入口；Android 端围绕刷卡找笼、查看当前状态和连续作业组织页面，接入语音反馈与失败提示。
处理真实使用中的边界
补齐生产中鸽笼的首次接入、未知历史的表达和受限纠错。维护 NFC 监听交接、同卡去重和过期请求检查，避免一次操作影响下一次作业。
业务背景
鸽场的记录围绕一排排笼位展开：今天查没查蛋，哪一窝要抽蛋或留窝，哪些幼崽需要转移。现场人员关心的是找到笼位、完成眼前的操作；管理人员则需要按栋舍查看待办和汇总。两端看到的状态必须一致，历史记录也不能在下一轮生产开始后混在一起。
核心流程
- 01
刷卡找到当前笼位
读到 UID 后查绑定关系，再校验当前账号会话和栋舍。未绑定、跨栋或上下文已变化时，提示并停止跳转。
- 02
按当前状态完成作业
后端给出可操作的业务状态；现场端进入相应页面。生产中首次接入只补问这次操作必需的信息，不要求补造整段历史。
- 03
留下记录并继续下一笼
后端保存生产动作，管理端通过工作表与历史记录查看结果。连续作业替换当前操作页，避免每刷一笼就堆一层页面。
一张笼位卡，怎样找到眼前这笼？
技术难点
生产已经在进行，历史却不完整
接入系统时，有的笼里已经有蛋或幼崽。如果要求先补齐上笼日期、原始放仔数量等全部信息，现场很难填；用默认值补齐，又会把猜测写成真实产量。
我把“新建笼”和“生产中笼”分开。生产中笼先标记待初始化，第一次实际作业时建立生产起点，只收集这次操作必需的数据。未知原始数量保留为空；用于推算的日期起点与真实生产事件分别标记。首次初始化和本次操作一起保存，重复请求返回同一结果。
建笼不再等于发生了一次生产动作。已知状态可以继续使用，未知历史也不会被伪装成零值或实际产量；纠错只在同业务日、无后续依赖等条件下开放。
连续刷卡时，旧页面不能干扰新作业
同一张卡可能被连续读到。页面跳转后，旧查询也可能才返回，甚至旧页面的卸载逻辑把新页面的监听关掉。只处理“读到了卡”，还不够支撑连续作业。
我把 UID 读取与页面业务分开，用会话和回调所有者管理监听。保留两秒同卡去重，查询处理中不排队；旧会话事件和旧页面的停止操作不能影响新会话。异步查询返回后再核对账号会话与栋舍；刷到正在操作的同一笼时保留表单。
读卡、查笼和页面切换有了明确的交接规则。后端统一提供业务日期，生命周期也隔离前后两轮生产，避免端上时间和历史状态各算一套。
项目成果
把管理与现场作业接在一起
完成后端业务接口、Web 管理界面和 Android 作业端。现场人员通过刷卡找到笼位并记录操作，管理人员按栋舍查看待办、工作表与历史。
让生产中的鸽笼也能接入
首次实际作业时只补充必需信息，将已有生产状态带入系统；未知历史单独表达，避免把初始化数据算成实际产量。
支撑逐笼连续作业
刷卡、查笼与页面切换按会话交接，同卡重复读取和旧页面回调分别处理，让工作人员完成一笼后继续下一笼。