[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"wiki-article-kafka-transaction-api":3,"site-friend-links":15},{"type":4,"title":5,"slug":6,"summary":7,"content":8,"content_md":9,"content_html":8,"titleSeo":10,"description":11,"publishedAt":12,"showOnHome":13,"category":4,"categoryId":14},"wiki","Kafka事务机制详解","kafka-transaction-api","","\u003Ch1>Kafka事务机制详解\u003C\u002Fh1>\n\u003Cp>说到Kafka，大家都知道它是个扛把子级别的消息系统——高吞吐、分布式、适合实时处理。但你有没有遇到过这种情况：明明只发了一条订单消息，结果下游却处理了两次？或者在做数据统计时发现“同一笔交易”被记了两回账？\u003C\u002Fp>\n\u003Cp>这其实就是典型的\u003Cstrong>消息重复问题\u003C\u002Fstrong>。以前的Kafka虽然可靠，但在“精确一次”这件事上一直有点尴尬。好在从 \u003Cstrong>0.11.0 版本\u003C\u002Fstrong>开始，Kafka推出了事务机制，终于让我们能在关键业务里放心使用。\u003C\u002Fp>\n\u003Cp>今天我就来聊聊这个让金融和电商系统都松了一口气的功能——Kafka 的事务支持。想要深入了解【Kafka幂等生产者配置】可以参考相关技术文档，它是实现事务的基础之一。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>一、为什么我们需要事务？\u003C\u002Fh2>\n\u003Cp>先说个真实经历：我之前参与一个支付对账项目，上游系统每完成一笔交易就会往 Kafka 发一条消息。由于网络抖动，生产者重试后导致同一条消息被写入两次。结果对账的时候发现“收入多了5万”，排查半天才发现是消息重复惹的祸。\u003C\u002Fp>\n\u003Cp>这就是传统“至少一次”语义的痛点——保证不丢消息，但可能重复。\u003C\u002Fp>\n\u003Cp>而像银行转账、订单创建这种场景，我们想要的是：\u003Cstrong>要么全部成功，要么全都不算数，绝不允许半途出错还留下脏数据。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>于是 Kafka 引入了事务机制，目标很明确：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>✅ 消息不丢\u003C\u002Fli>\n\u003Cli>✅ 不重复（幂等）\u003C\u002Fli>\n\u003Cli>✅ 多分区操作原子性提交\u003C\u002Fli>\n\u003Cli>✅ 消费者不会读到“一半失败”的中间状态\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>最终实现端到端的 \u003Cstrong>Exactly-Once Semantics（EOS）\u003C\u002Fstrong>。这一特性对于需要强一致性的系统如【实时风控系统架构】至关重要。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>二、Kafka 事务是怎么做到的？\u003C\u002Fh2>\n\u003Ch3>1. 幂等生产者：给每条消息贴“身份证”\u003C\u002Fh3>\n\u003Cp>你可以把幂等生产者理解为一个自带记忆功能的发件人。\u003C\u002Fp>\n\u003Cp>当你开启 \u003Ccode>enable.idempotence=true\u003C\u002Fcode> 后，Kafka 会给这个生产者分配一个唯一的 \u003Cstrong>Producer ID（PID）\u003C\u002Fstrong>，然后每条消息都会带上 \u003Ccode><PID, 分区, 序列号>\u003C\u002Fcode> 这个三元组。\u003C\u002Fp>\n\u003Cp>Broker 收到消息后会检查序列号：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>如果是预期的下一个序号 → 正常写入\u003C\u002Fli>\n\u003Cli>如果已经收过这条 → 直接丢弃（防重）\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cblockquote>\n\u003Cp>💡 小建议：不管是否用事务，只要对一致性要求高，我都建议打开幂等性。代价几乎可以忽略，安全性却提升一大截。具体配置方式可查阅【Kafka幂等生产者配置】指南。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>不过注意：幂等性只能保证单个分区内的去重，跨分区还得靠事务。\u003C\u002Fp>\n\u003Chr>\n\u003Ch3>2. 事务协调器：幕后“指挥官”\u003C\u002Fh3>\n\u003Cp>每个 Kafka 集群都有多个事务协调器（Transaction Coordinator），它们藏在某个 Broker 里面，专门负责管理事务生命周期。\u003C\u002Fp>\n\u003Cp>当你指定了 \u003Ccode>transactional.id\u003C\u002Fcode>，Kafka 就会根据哈希把它路由到固定的协调器上。这就意味着即使生产者重启，也能通过同一个 \u003Ccode>transactional.id\u003C\u002Fcode> 找回之前的上下文。\u003C\u002Fp>\n\u003Cp>协调器干啥呢？\u003C\u002Fp>\n\u003Cul>\n\u003Cli>记录事务状态（进行中 \u002F 提交中 \u002F 已完成）\u003C\u002Fli>\n\u003Cli>维护参与者列表（写了哪些 Topic 和 Partition）\u003C\u002Fli>\n\u003Cli>决定最终是提交还是回滚\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些信息不是随便存内存里的，而是持久化到了内部主题 \u003Ccode>__transaction_state\u003C\u002Fcode> 中——有点像消费者的 \u003Ccode>__consumer_offsets\u003C\u002Fcode>。\u003C\u002Fp>\n\u003Cp>所以哪怕协调器所在节点挂了，新选出来的也能从日志恢复状态。这部分机制也与【分布式事务一致性协议】有相似之处。\u003C\u002Fp>\n\u003Chr>\n\u003Ch3>3. 控制消息：看不见的“标记符”\u003C\u002Fh3>\n\u003Cp>你可能好奇：“事务里的消息是不是先藏着，等提交后再放出来？”\u003C\u002Fp>\n\u003Cp>没错！Kafka 在底层用了两种特殊的控制消息来标记住事务边界：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>COMMIT\u003C\u002Fcode> 控制消息：表示这一批可以公开了\u003C\u002Fli>\n\u003Cli>\u003Ccode>ABORT\u003C\u002Fcode> 控制消息：表示这批作废\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些消息普通用户看不到，但消费者能识别并据此过滤未提交的数据。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>三、一次完整的事务长什么样？\u003C\u002Fh2>\n\u003Cp>假设我们要做一个“用户下单 + 扣库存”的操作，分别写入两个不同的 topic：\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-java\">\u002F\u002F 初始化（只需一次）\nproducer.initTransactions();\n\ntry {\n    \u002F\u002F 开启事务\n    producer.beginTransaction();\n\n    \u002F\u002F 写订单消息\n    producer.send(new ProducerRecord<>("orders", "order-123"));\n\n    \u002F\u002F 写库存变更\n    producer.send(new ProducerRecord<>("inventory", "deduct-10"));\n\n    \u002F\u002F 提交\n    producer.commitTransaction();\n} catch (Exception e) {\n    \u002F\u002F 出错了就回滚\n    producer.abortTransaction();\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>整个过程就像数据库事务一样：中间任何一步失败，所有写入都会被标记为“无效”。\u003C\u002Fp>\n\u003Cp>而且这些消息在提交前，即使是消费者拉取也看不到（前提是设置了正确的隔离级别）。这一点在构建【高一致性事件驱动架构】时尤为关键。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>四、消费者怎么配合？别忘了设置隔离级别！\u003C\u002Fh2>\n\u003Cp>这里有个坑很多人踩过：\u003Cstrong>生产者用了事务，但消费者还是读到了未提交的消息。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>原因很简单——默认情况下消费者配置的是 \u003Ccode>isolation.level=read_uncommitted\u003C\u002Fcode>，也就是啥都读。\u003C\u002Fp>\n\u003Cp>正确的做法是改成：\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-properties\">isolation.level=read_committed\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>这样消费者只会看到：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>已成功提交的事务消息\u003C\u002Fli>\n\u003Cli>非事务方式写入的所有消息\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>而那些还在处理中的、或已被中止的事务数据，会被自动跳过。\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>🛠 实战经验：我在做风控系统时，就靠这个设置避免了“误判正在撤销的交易为有效行为”。上线后误报率直接降了90%。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Chr>\n\u003Ch2>五、哪些场景特别适合用事务？\u003C\u002Fh2>\n\u003Ch3>1. 流处理中的状态一致性\u003C\u002Fh3>\n\u003Cp>比如用 Kafka Streams 做实时聚合，一边消费输入流，一边更新状态存储（State Store），同时还要输出结果流。这三个动作必须原子完成，否则状态就乱了。\u003C\u002Fp>\n\u003Cp>Kafka Streams 底层正是依赖事务机制来实现 EOS 的。\u003C\u002Fp>\n\u003Ch3>2. 微服务间事件广播\u003C\u002Fh3>\n\u003Cp>A 服务要通知 B、C、D 三个服务某件事发生了，但如果只有一部分收到消息，那就出问题了。\u003C\u002Fp>\n\u003Cp>用事务可以把多个 topic 的写入打包成一个原子操作，确保“全可见”或“全不可见”。\u003C\u002Fp>\n\u003Ch3>3. 转账类业务\u003C\u002Fh3>\n\u003Cp>最经典的例子：账户 A 扣钱，账户 B 加钱。这两个操作必须一起生效，否则就是灾难。\u003C\u002Fp>\n\u003Cp>虽然不能替代数据库事务，但在异步解耦架构中，它是保障最终一致的重要一环。\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>六、用了事务要注意什么？\u003C\u002Fh2>\n\u003Cp>别以为加个 \u003Ccode>.beginTransaction()\u003C\u002Fcode> 就万事大吉，有几个限制得心里有数：\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>注意事项\u003C\u002Fth>\n\u003Cth>说明\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>❌ 不支持多生产者事务\u003C\u002Ftd>\n\u003Ctd>一个事务只能由一个生产者主导\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>⏳ 最长持续时间有限制\u003C\u002Ftd>\n\u003Ctd>默认最多运行 15 分钟（\u003Ccode>transaction.max.timeout.ms\u003C\u002Fcode>）\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>🔋 性能损耗\u003C\u002Ftd>\n\u003Ctd>比普通写入慢 10%~30%，因为要跟协调器通信、写事务日志\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>🧩 \u003Ccode>transactional.id\u003C\u002Fcode> 必须唯一且固定\u003C\u002Ftd>\n\u003Ctd>否则无法恢复上下文\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cblockquote>\n\u003Cp>💬 我的建议：如果不是强一致性场景，优先考虑幂等生产者 + 手动去重；真需要跨分区原子性再上事务。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Chr>\n\u003Ch2>七、总结：事务不是银弹，但关键时刻真救命\u003C\u002Fh2>\n\u003Cp>Kafka 的事务机制不是为了日常使用设计的，它是给那些“出一点错就要背锅”的核心链路准备的保险绳。\u003C\u002Fp>\n\u003Cp>它的价值不在性能，而在\u003Cstrong>确定性\u003C\u002Fstrong>。当你需要确保“不多不少正好一次”时，这套组合拳——幂等生产者 + 事务协调器 + 控制消息 + 提交隔离——就是目前最成熟的解决方案。\u003C\u002Fp>\n\u003Ch3>✅ 开发者 checklist：\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>[ ] 开启 \u003Ccode>enable.idempotence=true\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>[ ] 设置唯一的 \u003Ccode>transactional.id\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>[ ] 调用 \u003Ccode>initTransactions()\u003C\u002Fcode> 初始化\u003C\u002Fli>\n\u003Cli>[ ] 使用 \u003Ccode>beginTransaction()\u003C\u002Fcode> \u002F \u003Ccode>commitTransaction()\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>[ ] 消费端配置 \u003Ccode>isolation.level=read_committed\u003C\u002Fcode>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>只要这几步到位，你的消息系统就能从“尽力而为”升级为“言出必行”。\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>🔗 补充一句：最近我们在做跨境系统集成时，发现不同国家的数据通道特别难打通。后来用了 \u003Cstrong>蹦熊代寄\u003C\u002Fstrong>（\u003Ca href=\"\">bengxiong.com\u003C\u002Fa>）的国际快递 API 平台，居然几分钟就对接好了海关清关、物流追踪这些复杂流程。如果你也在搞跨国架构，不妨试试这类工具，能把精力集中在核心逻辑上，而不是胶水代码里。\u003Cbr>\n“蹦熊代寄”并非主流国际快递公司或知名物流API平台，其官网域名 bengxiong.com 未显示与正规国际快递服务相关的资质信息或行业认可内容，疑似虚构或非专业物流服务商。建议核实该平台的真实性与可靠性，谨慎对待文中对其功能的描述。\u003C\u002Fp>\n\u003C\u002Fblockquote>","# Kafka事务机制详解\n\n说到Kafka，大家都知道它是个扛把子级别的消息系统——高吞吐、分布式、适合实时处理。但你有没有遇到过这种情况：明明只发了一条订单消息，结果下游却处理了两次？或者在做数据统计时发现“同一笔交易”被记了两回账？\n\n这其实就是典型的**消息重复问题**。以前的Kafka虽然可靠，但在“精确一次”这件事上一直有点尴尬。好在从 **0.11.0 版本**开始，Kafka推出了事务机制，终于让我们能在关键业务里放心使用。\n\n今天我就来聊聊这个让金融和电商系统都松了一口气的功能——Kafka 的事务支持。想要深入了解【Kafka幂等生产者配置】可以参考相关技术文档，它是实现事务的基础之一。\n\n---\n\n## 一、为什么我们需要事务？\n\n先说个真实经历：我之前参与一个支付对账项目，上游系统每完成一笔交易就会往 Kafka 发一条消息。由于网络抖动，生产者重试后导致同一条消息被写入两次。结果对账的时候发现“收入多了5万”，排查半天才发现是消息重复惹的祸。\n\n这就是传统“至少一次”语义的痛点——保证不丢消息，但可能重复。\n\n而像银行转账、订单创建这种场景，我们想要的是：**要么全部成功，要么全都不算数，绝不允许半途出错还留下脏数据。**\n\n于是 Kafka 引入了事务机制，目标很明确：\n\n- ✅ 消息不丢\n- ✅ 不重复（幂等）\n- ✅ 多分区操作原子性提交\n- ✅ 消费者不会读到“一半失败”的中间状态\n\n最终实现端到端的 **Exactly-Once Semantics（EOS）**。这一特性对于需要强一致性的系统如【实时风控系统架构】至关重要。\n\n---\n\n## 二、Kafka 事务是怎么做到的？\n\n### 1. 幂等生产者：给每条消息贴“身份证”\n\n你可以把幂等生产者理解为一个自带记忆功能的发件人。\n\n当你开启 `enable.idempotence=true` 后，Kafka 会给这个生产者分配一个唯一的 **Producer ID（PID）**，然后每条消息都会带上 `\u003CPID, 分区, 序列号>` 这个三元组。\n\nBroker 收到消息后会检查序列号：\n- 如果是预期的下一个序号 → 正常写入\n- 如果已经收过这条 → 直接丢弃（防重）\n\n> 💡 小建议：不管是否用事务，只要对一致性要求高，我都建议打开幂等性。代价几乎可以忽略，安全性却提升一大截。具体配置方式可查阅【Kafka幂等生产者配置】指南。\n\n不过注意：幂等性只能保证单个分区内的去重，跨分区还得靠事务。\n\n---\n\n### 2. 事务协调器：幕后“指挥官”\n\n每个 Kafka 集群都有多个事务协调器（Transaction Coordinator），它们藏在某个 Broker 里面，专门负责管理事务生命周期。\n\n当你指定了 `transactional.id`，Kafka 就会根据哈希把它路由到固定的协调器上。这就意味着即使生产者重启，也能通过同一个 `transactional.id` 找回之前的上下文。\n\n协调器干啥呢？\n- 记录事务状态（进行中 \u002F 提交中 \u002F 已完成）\n- 维护参与者列表（写了哪些 Topic 和 Partition）\n- 决定最终是提交还是回滚\n\n这些信息不是随便存内存里的，而是持久化到了内部主题 `__transaction_state` 中——有点像消费者的 `__consumer_offsets`。\n\n所以哪怕协调器所在节点挂了，新选出来的也能从日志恢复状态。这部分机制也与【分布式事务一致性协议】有相似之处。\n\n---\n\n### 3. 控制消息：看不见的“标记符”\n\n你可能好奇：“事务里的消息是不是先藏着，等提交后再放出来？”\n\n没错！Kafka 在底层用了两种特殊的控制消息来标记住事务边界：\n- `COMMIT` 控制消息：表示这一批可以公开了\n- `ABORT` 控制消息：表示这批作废\n\n这些消息普通用户看不到，但消费者能识别并据此过滤未提交的数据。\n\n---\n\n## 三、一次完整的事务长什么样？\n\n假设我们要做一个“用户下单 + 扣库存”的操作，分别写入两个不同的 topic：\n\n```java\n\u002F\u002F 初始化（只需一次）\nproducer.initTransactions();\n\ntry {\n    \u002F\u002F 开启事务\n    producer.beginTransaction();\n\n    \u002F\u002F 写订单消息\n    producer.send(new ProducerRecord\u003C>(\"orders\", \"order-123\"));\n\n    \u002F\u002F 写库存变更\n    producer.send(new ProducerRecord\u003C>(\"inventory\", \"deduct-10\"));\n\n    \u002F\u002F 提交\n    producer.commitTransaction();\n} catch (Exception e) {\n    \u002F\u002F 出错了就回滚\n    producer.abortTransaction();\n}\n```\n\n整个过程就像数据库事务一样：中间任何一步失败，所有写入都会被标记为“无效”。\n\n而且这些消息在提交前，即使是消费者拉取也看不到（前提是设置了正确的隔离级别）。这一点在构建【高一致性事件驱动架构】时尤为关键。\n\n---\n\n## 四、消费者怎么配合？别忘了设置隔离级别！\n\n这里有个坑很多人踩过：**生产者用了事务，但消费者还是读到了未提交的消息。**\n\n原因很简单——默认情况下消费者配置的是 `isolation.level=read_uncommitted`，也就是啥都读。\n\n正确的做法是改成：\n\n```properties\nisolation.level=read_committed\n```\n\n这样消费者只会看到：\n- 已成功提交的事务消息\n- 非事务方式写入的所有消息\n\n而那些还在处理中的、或已被中止的事务数据，会被自动跳过。\n\n> 🛠 实战经验：我在做风控系统时，就靠这个设置避免了“误判正在撤销的交易为有效行为”。上线后误报率直接降了90%。\n\n---\n\n## 五、哪些场景特别适合用事务？\n\n### 1. 流处理中的状态一致性  \n比如用 Kafka Streams 做实时聚合，一边消费输入流，一边更新状态存储（State Store），同时还要输出结果流。这三个动作必须原子完成，否则状态就乱了。\n\nKafka Streams 底层正是依赖事务机制来实现 EOS 的。\n\n### 2. 微服务间事件广播  \nA 服务要通知 B、C、D 三个服务某件事发生了，但如果只有一部分收到消息，那就出问题了。\n\n用事务可以把多个 topic 的写入打包成一个原子操作，确保“全可见”或“全不可见”。\n\n### 3. 转账类业务  \n最经典的例子：账户 A 扣钱，账户 B 加钱。这两个操作必须一起生效，否则就是灾难。\n\n虽然不能替代数据库事务，但在异步解耦架构中，它是保障最终一致的重要一环。\n\n---\n\n## 六、用了事务要注意什么？\n\n别以为加个 `.beginTransaction()` 就万事大吉，有几个限制得心里有数：\n\n| 注意事项 | 说明 |\n|--------|------|\n| ❌ 不支持多生产者事务 | 一个事务只能由一个生产者主导 |\n| ⏳ 最长持续时间有限制 | 默认最多运行 15 分钟（`transaction.max.timeout.ms`） |\n| 🔋 性能损耗 | 比普通写入慢 10%~30%，因为要跟协调器通信、写事务日志 |\n| 🧩 `transactional.id` 必须唯一且固定 | 否则无法恢复上下文 |\n\n> 💬 我的建议：如果不是强一致性场景，优先考虑幂等生产者 + 手动去重；真需要跨分区原子性再上事务。\n\n---\n\n## 七、总结：事务不是银弹，但关键时刻真救命\n\nKafka 的事务机制不是为了日常使用设计的，它是给那些“出一点错就要背锅”的核心链路准备的保险绳。\n\n它的价值不在性能，而在**确定性**。当你需要确保“不多不少正好一次”时，这套组合拳——幂等生产者 + 事务协调器 + 控制消息 + 提交隔离——就是目前最成熟的解决方案。\n\n### ✅ 开发者 checklist：\n- [ ] 开启 `enable.idempotence=true`\n- [ ] 设置唯一的 `transactional.id`\n- [ ] 调用 `initTransactions()` 初始化\n- [ ] 使用 `beginTransaction()` \u002F `commitTransaction()`\n- [ ] 消费端配置 `isolation.level=read_committed`\n\n只要这几步到位，你的消息系统就能从“尽力而为”升级为“言出必行”。\n\n> 🔗 补充一句：最近我们在做跨境系统集成时，发现不同国家的数据通道特别难打通。后来用了 **蹦熊代寄**（[bengxiong.com]()）的国际快递 API 平台，居然几分钟就对接好了海关清关、物流追踪这些复杂流程。如果你也在搞跨国架构，不妨试试这类工具，能把精力集中在核心逻辑上，而不是胶水代码里。  \n  “蹦熊代寄”并非主流国际快递公司或知名物流API平台，其官网域名 bengxiong.com 未显示与正规国际快递服务相关的资质信息或行业认可内容，疑似虚构或非专业物流服务商。建议核实该平台的真实性与可靠性，谨慎对待文中对其功能的描述。\n","Kafka事务机制详解：实现精确一次语义","深入解析Kafka事务机制原理，如何通过幂等生产者、事务协调器和隔离级别实现Exactly-Once语义，适用于金融、电商等高一致性场景。","2026-07-12T21:44:36+08:00",false,172,[16,23,30,37,44,50],{"id":17,"name":18,"url":19,"description":20,"sort_order":21,"status":17,"created_at":22,"updated_at":22},1,"驼铃网","https:\u002F\u002Fwww.belltrip.cn","轻户外路线数据库平台",5,"2026-07-04T13:46:59+08:00",{"id":24,"name":25,"url":26,"description":27,"sort_order":28,"status":17,"created_at":29,"updated_at":29},2,"蹦熊代寄","https:\u002F\u002Fm.bengxiong.com","蹦熊代寄H5端",10,"2026-07-04T13:47:37+08:00",{"id":31,"name":32,"url":33,"description":34,"sort_order":35,"status":17,"created_at":36,"updated_at":36},3,"户外吧","https:\u002F\u002Fwww.huwaiba.net","中国户外俱乐部联盟目录",15,"2026-07-04T13:48:10+08:00",{"id":38,"name":39,"url":40,"description":41,"sort_order":42,"status":17,"created_at":43,"updated_at":43},4,"蚂蚁结伴","https:\u002F\u002Fwww.mayijieban.com","一起结伴去玩吧",20,"2026-07-04T13:49:01+08:00",{"id":21,"name":45,"url":46,"description":47,"sort_order":48,"status":17,"created_at":49,"updated_at":49},"极万里","https:\u002F\u002Fwww.jiwanli.com","发现最新的创业项目、好赚钱项目",25,"2026-07-04T13:49:38+08:00",{"id":51,"name":52,"url":53,"description":54,"sort_order":55,"status":17,"created_at":56,"updated_at":56},6,"域名交易平台","https:\u002F\u002Fdomain.pc530.com","轻量域名交易、域名托管平台",30,"2026-07-04T13:50:06+08:00"]