企业官网建设流程全解析

简介：闲鱼自动发货系统是一套基于闲鱼API的开源自动化交易工具，主要面向虚拟商品卖家及有Python基础的开发者，用于解决自动发货、消息自动回复和智能客服等重复性操作问题。项目采用Python 3.7+与asyncio异步架构，内置自定义回复、消息变量替换及ChatGPT/文心一言等大模型对接能力，并配合错误重试、超时处理与完备日志，适合各类虚拟商品的批量交易场景。压缩包共27个文件，以Python源码和编译文件为主，包含9个py、6个pyc、3个js脚本，以及yml配置文件、日志文件、Dockerfile和说明文档等，整体约751KB。源码中可见xianyu_utils、message_utils、ws_utils等模块划分，global_config.yml可快速个性化配置，Dockerfile便于部署。目前已有1307人学习，资源提供可运行工程与API接口文档，上手后可快速搭建属于自己的闲鱼自动发货服务。

1. 闲鱼自动发货系统：它到底解决了谁的什么痛点

凌晨两点卖出第一单，早上醒来才看到消息，买家已经等得不耐烦；白天上班没法盯手机，顾客拍下后问“老板在吗”问了一下午——这是每个闲鱼卖家都经历过的场景。闲鱼自动发货系统就是为这种“人不在但订单在”的矛盾设计的：它监听订单状态变化，一旦检测到买家已付款且待发货，就自动从卡密仓库取一条未使用的卡密或网盘链接，执行发货动作，并把订单标记为已完成发货，全程不需要人碰手机。适合高频出卡的数码点券卖家、卖资料包和课程链接的内容卖家，以及同时运营多个账号的兼职卖家。它的核心价值不是“省掉点一下鼠标的时间”，而是把发货这件事从人工时延变成秒级响应，直接减少买家等待带来的退款率和差评。需要说明的是，任何自动化都要在平台规则允许的范围内使用，本文的目标是把技术原理讲透，让你能判断这类系统靠不靠谱、怎么搭一套自己能掌控的最小版本。

2. 先看懂闲鱼发货的底层状态流转，再谈自动化

2.1 一笔订单从拍下到完成，中间有几个必须盯的状态节点

闲鱼的发货流程和传统电商平台有区别：没有独立的“发货”按钮式物流对接，而是以“闲鱼小站”或聊天窗口内的“发货”动作来触发。状态节点大致是：买家拍下（订单创建）→ 买家付款（待发货）→ 卖家点击发货（已发货）→ 买家确认收货（交易完成）。自动化系统真正要盯的只有两个关键节点：一是“待发货”状态的出现，二是“已发货”状态是否已经写入记录。

很多初次接触自动发货的人会去抓所谓的“新订单通知”，这是一个常见的认知偏差。闲鱼没有开放给个人的订单推送接口，市面上的自动发货工具，本质都是对页面数据或本地通知做监听。常见做法有两种：一种是轮询订单列表接口，比对数据里的订单状态字段；另一种是从桌面端的通知气泡或者浏览器插件里截取信息。工程上更常见也更稳的是轮询方案，因为它不依赖弹窗，也不会因为系统通知被折叠而漏单。

这里有一个容易被忽略的细节：订单状态字段的取值在不同端（iOS、Android、桌面端）展示有差异，但底层数据里通常包含一个数字状态码。自动化脚本的逻辑不是去识别“待发货”这三个汉字，而是识别数值型状态标志的变化。多花五分钟把这个字段值摸清，后面会省掉大量调试时间。

2.2 两条技术路线：模拟点击 vs 数据流驱动，选型决定稳定性

目前做闲鱼自动发货，工程上有两条技术路线。第一条是模拟点击路线：用自动化测试工具控制浏览器或桌面客户端，定位“发货”按钮坐标并执行点击。优点是开发门槛低，缺点是平台页面一改版脚本就作废，而且模拟点击最容易触发风控，因为它模拟的是人的动作，但动作轨迹却非常机械。

第二条是数据流驱动路线：不走界面点按，而是监听本地代理或调试端口的数据流，当数据流中出现“买家已付款”的信号时，调用内部函数直接改写订单状态并发送发货内容。这条路线对开发者要求更高，但稳定性强，因为数据接口的结构变化频率远低于界面样式变化。我一般会建议有条件的人直接走数据流路线，哪怕是半成品，维护成本也比模拟点击低一个量级。

选型时还要考虑一个边界：自动发货不等于自动确认收货，也不等于自动回复买家消息。一个好的系统设计，应该把“自动发货”限定在从“待发货”到“已发货”这一段，收货确认和售后沟通保留人工控制。这个边界划得越清楚，系统的风险面越小。

2.3 用状态机模型描述发货流程，避免逻辑漏洞

把发货流程写成代码前，先用状态机把逻辑画清楚。订单有三个核心状态：PENDING（待发货）、SHIPPED（已发货）、FAILED（发货失败）。自动发货系统的任务就是在这三个状态之间做合法迁移，任何不在定义表里的状态组合都应该被拒绝。

# 状态定义与迁移规则 ORDER_STATES = { "PENDING": 0, # 待发货：买家已付款，系统未处理 "SHIPPED": 1, # 已发货：系统已发送卡密/链接 "FAILED": 2, # 发货失败：需要人工介入 } # 合法的状态迁移表 TRANSITIONS = { "PENDING": ["SHIPPED", "FAILED"], # 待发货只能走向已发货或失败 "SHIPPED": [], # 已发货是终态，不接受二次发货 "FAILED": ["PENDING"], # 失败后允许重置为待发货重试 }

这段代码的价值不在于复杂，而在于强约束。很多自动发货翻车都出在“重复发货”上：脚本第一次发货后网络超时，误判为失败，重试时又发了一次。有了状态迁移表，代码里只需要一行判断就能拦住这种问题：只有当订单当前状态是 PENDING 且目标状态是 SHIPPED 时，才执行发货动作。参数上要注意：迁移表一旦写入生产环境，不要因为某个极端场景临时改表结构，宁可加一个 FAILED 分支让人工处理，也不要破坏终态约束。

3. 搭一套最小可运行的自动发货引擎：订单监听、发货执行与防重

3.1 整体架构与本地存储设计

完整的最小系统由三个模块组成：订单监听器、发货执行器、状态存储。三者之间的关系是：监听器定期从订单数据源拉取状态快照，对比本地存储中的记录，发现新出现的待发货订单就交给执行器；执行器从卡密仓库取一条卡密，构造发货内容，执行发货动作，最后回写状态存储。

存储层面我推荐直接用 SQLite，不需要引入独立的数据库服务。原因有三个：单文件备份方便、事务支持完整、对零部署要求的小工具来说足够用了。表设计上需要两张表：一张是订单表，记录订单号、当前状态、发货内容、时间戳；另一张是卡密表，记录卡密内容、状态（未使用/已使用/作废）、分配到的订单号。卡密表和订单表的关联字段是订单号，这样后续查账时能直接知道某笔订单发的是哪条卡密。

-- 订单表 CREATE TABLE orders ( order_id TEXT PRIMARY KEY, -- 闲鱼订单号，唯一约束 state INTEGER DEFAULT 0, -- 0=待发货 1=已发货 2=失败 shipped_content TEXT, -- 实际发货的卡密或链接 created_at TEXT, -- 订单创建时间 shipped_at TEXT -- 发货完成时间 ); -- 卡密表 CREATE TABLE cards ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, -- 卡密内容或网盘链接 status INTEGER DEFAULT 0, -- 0=未使用 1=已使用 2=作废 order_id TEXT -- 被分配给哪个订单 );

这个表结构建议不要精简。实际开发中很容易犯的错是只建一张表，把卡密内容直接塞进订单记录，结果同一张卡被发了两回都不知道。两张表分离之后，通过 SQL 的 JOIN 就能查出“已被使用的卡密ID 和对应订单号”，排查效率会高很多。SQLite 的并发写能力虽然有限，但对于个人卖家的订单量（每天几十到几百单）完全够用。

3.2 订单监听器：轮询策略与状态比对算法

监听器的核心是一个轮询循环。最朴素的实现是每隔几秒拉一次订单数据，和本地库里的订单号做差集，发现新订单就进入发货流程。这个方案的关键参数有两个：轮询间隔和超时时间。轮询间隔太短会增加被平台风控盯上的概率，太长则丧失“自动”的意义。经过多台设备验证，3到5秒是一个比较稳的区间；网络超时设定为10秒，超过即判定本轮失败，下轮继续。

import time import sqlite3 POLL_INTERVAL = 4 # 轮询间隔：4秒，兼顾实时性与风控友好 REQUEST_TIMEOUT = 10 # 单次请求超时：10秒 def fetch_remote_orders(): """拉取远端订单列表，返回 [{"id": "12345", "state": "PAID"}, ...]""" # 常见做法是从本地代理端口的 JSON 数据流中解析 # 这里用 mock 数据代替，逻辑保持不变 return [{"id": "12345", "state": "PAID"}] def poll_once(conn): """执行一次轮询：拉取数据、比对、发现新订单""" remote_orders = fetch_remote_orders() local_ids = set(row[0] for row in conn.execute("SELECT order_id FROM orders")) for order in remote_orders: oid = order["id"] if oid not in local_ids: # 新订单，插入本地并标记为待发货 conn.execute( "INSERT INTO orders (order_id, state) VALUES (?, ?)", (oid, 0) ) conn.commit() print(f"[监听器] 发现新订单 {oid}，已进入待发货队列")

这里的核心技巧是：监听器不负责发货，它只负责“发现”和“入库”。把发现与执行拆成两个阶段，好处是即使发货动作抛异常，订单也已经持久化在本地库里，不会因为内存丢失而漏单。如果你观察到日志里出现了“新订单已入库但迟迟没有发货”的情况，优先检查监听器和执行器之间的队列通道，而不是检查网络。

3.3 发货执行器：取卡、发货、回写三步连招

执行器的逻辑是订单状态机里最核心的部分。它从数据库里挑出所有 state=0 的订单，逐一处理。处理流程分三步：先从卡密表里拿一条未使用的卡密并标记为“占用”，然后执行发货动作（常见实现是调用页面发货模块的接口或直接写入发货内容），最后把订单状态改成“已发货”，并把卡密的 order_id 回填。三步必须放在同一个事务里，中间任何一步失败都要回滚。

def ship_order(conn, order_id): """执行发货：取卡 -> 发货 -> 回写，全程事务保护""" try: conn.execute("BEGIN") # 第一步：取一条未使用的卡密，标记为占用 card = conn.execute( "SELECT id, content FROM cards WHERE status=0 LIMIT 1" ).fetchone() if card is None: raise RuntimeError(f"订单 {order_id} 无可用卡密，需要人工补充") # 第二步：模拟发货动作（实际调用发货接口） delivery_result = do_deliver(order_id, card["content"]) if not delivery_result.get("success"): raise RuntimeError(f"发货接口返回失败: {delivery_result}") # 第三步：回写订单状态 + 卡密分配关系 conn.execute( "UPDATE orders SET state=1, shipped_content=?, shipped_at=? WHERE order_id=?", (card["content"], time.time(), order_id) ) conn.execute( "UPDATE cards SET status=1, order_id=? WHERE id=?", (order_id, card["id"]) ) conn.commit() print(f"[执行器] 订单 {order_id} 发货成功") except Exception as e: conn.rollback() # 把失败订单标记为 FAILED，等待人工处理 conn.execute("UPDATE orders SET state=2 WHERE order_id=?", (order_id,)) conn.commit() print(f"[执行器] 订单 {order_id} 发货失败: {e}")

这段代码里的几个参数需要理解到位。BEGIN/COMMIT/ROLLBACK 是事务的边界，三行写在一起保证了“取卡”和“发货”要么同时成功，要么同时失败。state=2的失败标记非常关键：它把异常订单从自动化流程里摘出来，避免每次轮询都去重试一个已经注定失败的订单。实际运行时你会发现，绝大多数发货失败都发生在 do_deliver 这一步，比如网络超时或接口返回了非预期结构，所以 do_deliver 内部要做好异常捕获，能重试的尽量重试三次，三次后仍然失败再落 FAILED 状态。

3.4 主循环与日志：让系统自己告诉你它干了什么

主循环把监听器和执行器串起来。每轮先执行一次监听，然后执行一次发货扫描，中间休息一个轮询间隔。日志的粒度建议精确到单笔订单，格式统一为“时间 + 模块 + 动作 + 结果”，方便用 grep 排查。

def main(): conn = sqlite3.connect("auto_ship.db", check_same_thread=False) # 初始化表结构 init_db(conn) while True: try: # 第一步：监听新订单 poll_once(conn) # 第二步：扫描待发货订单，逐个执行 pending = conn.execute( "SELECT order_id FROM orders WHERE state=0" ).fetchall() for row in pending: ship_order(conn, row[0]) except Exception as e: # 防止单次异常导致整个循环退出 print(f"[主循环] 本轮执行异常: {e}") time.sleep(POLL_INTERVAL) if __name__ == "__main__": main()

主循环的容错处理是很多人容易忽略的。如果不包这一层 try-except，任何一次网络抖动都会让脚本直接崩溃，而且没有任何重启机制，第二天早上起来发现系统不知道什么时候已经停了。加了异常捕获之后，即使单轮失败，下一轮还能继续。另外一个细节是 SQLite 的连接要设置check_same_thread=False，因为后续如果接入多线程扩展，这个连接会被多个任务共享，不加这个参数会直接抛异常。

4. 卡密仓库与发货内容策略：自动发货的“弹药库”怎么建

4.1 卡密的批量导入与库存状态机

卡密仓库是自动发货系统的弹药库。常用的卡密形式有三类：纯文本卡密（激活码、兑换码）、网盘链接（带提取码）、自定义文本模板（比如虚拟商品说明）。导入方式上，最常见的是准备一个文本文件，每行一条，系统启动时批量读入数据库。

def import_cards(conn, filepath): """批量导入卡密，每行一条，自动去重""" imported = 0 with open(filepath, "r", encoding="utf-8") as f: for line in f: content = line.strip() if not content: continue # 防止重复导入同一张卡 exists = conn.execute( "SELECT 1 FROM cards WHERE content=?", (content,) ).fetchone() if exists: continue conn.execute( "INSERT INTO cards (content, status) VALUES (?, 0)", (content,) ) imported += 1 conn.commit() print(f"导入完成：新卡密 {imported} 条")

导入时最容易踩的坑是文件编码。Windows 记事本默认的 GBK 编码会让文件里的中文内容在 Python 里直接变成乱码，卡密内容一旦是乱码，发出去买家根本没法用。经验是用 UTF-8 with BOM 编码保存导入文件，读取时统一指定encoding="utf-8"。另外导入一定要去重，同一张卡密被导入两次，在后续分配时就会产生“两张卡发给两个订单，但内容完全一样”的严重事故。

4.2 发货内容模板：处理“文本+链接+说明”的组合场景

不是所有卡密都是单行文本。很多闲鱼卖家卖的是“网盘链接 + 提取码 + 使用说明 + 售后提示”的组合，这种内容如果直接以单行字符串存储，读取和拼装都会很麻烦。工程上更合理的做法是把模板拆成结构化字段：主文本、链接、附加说明，发货时自动拼接。

def build_delivery_content(template: dict, card_content: str) -> str: """根据模板拼装发货内容""" parts = [] if template.get("header"): parts.append(template["header"]) # 卡密正文：可能是纯文本，也可能是链接+提取码 parts.append(card_content) if template.get("footer"): parts.append(template["footer"]) # 用一条分隔线连接，避免内容挤在一起 return "\n---\n".join(parts) # 模板参数说明： # header: 固定话术，如“感谢购买，以下为您的卡密，请尽快使用” # footer: 售后说明，如“如有问题请提供订单号联系客服”

这里的关键参数是模板的 footer，建议在里面加入“请保留订单号”这句话，很多买家收到卡密后直接删聊天记录，出问题了又来找卖家，客服沟通成本极高。顺带说一句，发货内容里不要包含任何营销话术，闲鱼对虚拟商品的发货信息审核比较严格，内容越干净越安全。

4.3 卡密库存告警：自动发货系统变成“自动翻车系统”的最后一道防线

卡密仓库最大的风险不是库存为零，而是库存为零时没有人知道。自动发货系统一旦遇到无卡可用的订单，会把订单标记为 FAILED 并等待人工处理，但如果卖家没在看日志，这个订单就永远卡在失败状态里，买家那边收到的只有“卖家迟迟不发货”的体验。

一个务实解法是把告警接进日常通知渠道。常见做法是让系统在检测到库存为 0 时发一条消息到管理员的个人通知渠道，技术上用 webhook 就能实现。告警消息里必须包含两个信息：当前缺货的订单号、库里剩余卡密数量。很多自动发货工具只告警“库存不足”，却不告诉你是哪些订单受影响，等你去查的时候买家已经申请退款了。

def check_stock_and_alert(conn): """检查卡密库存，低于阈值时触发告警""" count = conn.execute("SELECT COUNT(*) FROM cards WHERE status=0").fetchone()[0] if count < STOCK_ALERT_THRESHOLD: # 阈值建议设为 10 pending_orders = conn.execute( "SELECT order_id FROM orders WHERE state=0" ).fetchall() message = { "type": "stock_alert", "remaining": count, "affected_orders": [o[0] for o in pending_orders] } send_alert(message) # 发送到管理后台或通知渠道

阈值设多少合适取决于卖家的补卡频率。如果每天补一次货，阈值设为 10 已经是安全线；如果每周才补一次货，阈值最好拉到 50。宁可多收几次告警，也不要在深夜被欠货的状态杀个措手不及。这条防线看起来简单，但有相当多的自动发货系统忽略了这个功能，等到买家集体退款才意识到问题。

5. 避坑指南：自动发货最常见的 4 个翻车现场

5.1 现象：买家付款了，系统没有发货，日志里什么都没有

原因：订单监听器的数据源解析失败，最常见的是平台侧字段结构变了，比如原来的state字段改成了status，或者嵌套层级加深了一层。

解决：不要只打印“无新订单”，把每次拉取到的原始数据截断后写入日志文件。发现漏发时先看原始数据长什么样，再比对解析逻辑哪里对不上。这类问题没有一劳永逸的解法，只能建立“监听器心跳日志”机制：每隔 10 分钟记录一次“拉取正常，当前无新订单”，如果连心跳日志都断了，说明程序已经退出。

5.2 现象：同一张卡密发给了两个不同订单

原因：并发冲突。如果系统在发货时没有使用事务，或者事务边界里先取了卡密再更新状态，两个线程可能同时读到同一条 status=0 的卡密。

解决：检查取卡逻辑里是否使用了BEGIN IMMEDIATE事务。在 SQLite 中，BEGIN默认是延迟事务，多个连接并发读时不会加写锁，只有使用BEGIN IMMEDIATE才能阻止其他连接同时操作。另外，给卡密表增加一个locked_by字段，取卡时先 UPDATE 锁定再 SELECT，双保险。

5.3 现象：发货成功但买家说没收到，后台却显示已发货

原因：发货内容拼接出错。多发生在模板配置阶段，比如 footer 里的文案缺失，或者卡密正文里包含换行符，导致实际发送时内容被截断，买家只看到一半。

解决：发货前做一次内容完整性校验，规则很简单：卡密内容不能为空、卡密内容不包含换行符、模板拼接后的总长度不超过平台限制。校验失败就让订单进入 FAILED，而不是强行发出。这条规则可以拦截掉 90% 的“假发货”。

5.4 现象：系统运行一段时间后自动停止，没有报错

原因：程序内存泄漏或者是父进程被系统回收。Python 脚本在长时间运行时，如果某个库存在内存泄漏，进程会逐渐膨胀，最终被 OOM Killer 杀掉；如果跑在系统服务里，服务可能因为超时或重启而中断。

解决：用系统守护工具把脚本注册为常驻服务，并加一个“健康检查”接口。健康检查的内容很简单：脚本启动后每 30 秒记录一次时间戳，外部监控定期检查这个时间戳是否更新。这个机制能保证即使脚本静默退出，也能在两分钟内被发现并且自动拉起。

6. 进阶：从单账号到多账号挂机，给自动发货系统做一次体检

自动发货系统跑通单账号之后，真正的价值释放来自多账号规模化。多账号部署的核心不是开多个进程，而是数据隔离和会话隔离：每个账号一套独立数据库文件，各自的订单、卡密、配置互不串扰。常见做法是目录按账号维度组织，每个账号目录下放data.db和config.yaml，进程启动时指定账号目录。这样做的好处是后期排查问题可以先定位账号目录，再查对应日志，不用在一堆混合数据里捞。

部署好后要做一轮系统体检，我习惯按这个顺序验证：先做一轮端到端回归，模拟一笔新订单进入系统，检查监听器是否入库、执行器是否发货、卡密表是否扣减；再做故障注入测试，主动断网 10 秒，看订单是否进入 FAILED 状态、恢复后能否重试；最后看冷启动恢复，杀掉进程重启，确认所有未发货订单还在队列里，不会因为重启而丢单。

还有一个容易被忽略的点：自动发货系统的运行时长与脚本语言的运行时稳定性强相关。如果你的环境是 Python，建议加一个定时重启机制，比如每天凌晨四点自动重启一次，把内存碎片化问题清零。跑得越久越稳这种想法在自动化工具领域是错的，反而是主动重启能消除大量隐性故障。

最后说句实在话：自动发货系统的核心价值不是把人工成本降为 0，而是把发货延迟从小时级降为秒级。做了这么久这类系统，我最大的一个教训是——自动化完成之后，人不是解放了，而是要腾出手来盯着库存补货和售后处理。真正跑得好的部署，永远是自动为主、人工兜底、监控不断。希望帮到你。

本文还有配套的精品资源，点击获取