什么是咸鱼自动发货
这是一套面向闲鱼虚拟商品交易的自动发货框架，重点不在于把所有发货方式写死，而是先把“什么时候该发货”这件事稳定下来。它持续监控闲鱼聊天页面，识别系统付款卡片，只有在消息类型、卡片文案和“去发货”按钮等条件同时满足时，才会触发后续流程。这样做的目的很明确：尽量避免把买家自己手打的“我已付款了”“老板发货”之类文本误判成真实付款通知。
从结构上看，这个项目把付款检测层和发货执行层拆开了。前者由框架负责，后者交给用户自己定义，因此它更像一个可扩展底座，而不是只支持单一玩法的小脚本。框架会在检测到付款后调用发货钩子，并把买家昵称、商品标题、订单金额、下单时间等上下文信息提供出来，用户可以据此决定要发送固定秘钥、从秘钥池取卡密、回传下载链接，还是进一步接入自己的业务逻辑。
这种设计让它比“自动发一句话”的方案更适合长期使用。一方面，项目内置了多种常见模板，覆盖固定秘钥、秘钥池、链接、图片、文件、API 调用和混合发货等虚拟商品常见场景，拿来即改即可；另一方面，它并不强制某一种实现方式，既能用脚本和配置文件快速落地，也能在外层接 Python、Node.js 等其他程序。对想把闲鱼虚拟商品发货流程做成半自动或自动化的人来说，这套框架提供的是一个可继续扩展的工作流骨架。
核心功能特点
- 用系统卡片和“去发货”按钮双重条件判断付款，减少把普通聊天消息误识别为已付款的情况
- 把付款检测与发货逻辑分离，框架负责触发时机，具体怎么发由用户通过钩子自由实现
- 内置固定秘钥、秘钥池、链接、图片、文件、API、混合发货等模板，便于按现有业务快速改造
- 发货时可读取买家昵称、商品标题、订单金额、下单时间等订单上下文，方便做个性化处理或外部集成
- 提供监控循环、日志记录与基础故障排查思路，便于持续运行和定位发货失败原因
适用场景
它最适合的首先是闲鱼上的虚拟商品卖家，尤其是售卖兑换码、会员卡密、网盘资源、电子书、教程资料等标准化内容的人。这类商品通常在买家付款后就能立即交付，如果还要手动盯聊天、复制文案、逐条发送，不仅重复劳动多，也容易在高峰期漏单。借助这个框架，卖家可以把确认付款后的动作固定下来，让系统自动进入发货步骤，把精力留给售后和商品维护。
如果你的商品交付方式并不统一，这套框架的价值会更明显。有人卖的是固定内容，适合直接发送同一份秘钥；有人每单都要分配不同卡密，需要维护秘钥池和已使用记录；也有人需要发送网盘链接、二维码截图、本地文件，甚至调用外部接口按买家或商品动态生成内容。由于项目只规定触发机制，不限制具体交付手段，因此比较适合这类“同一店铺、多种交付模式并存”的运营方式。
它也适合已经有一定自动化基础、希望把闲鱼纳入现有业务流程的人。比如你已经有自己的秘钥生成服务，或者需要把发货结果同步到内部系统，那么可以直接在发货钩子里调用 API，把检测到的订单上下文传给外部服务，再把返回结果发回聊天窗口。对于想做更细控制的人，日志、重试、限流、通知提醒等示例同样有参考价值。不过从证据看，图片和文件上传环节仍需要结合实际界面调整，因此更适合愿意自己动手配置、而不是追求完全零设置的一类用户。