基于Chrome扩展网关的LINE消息自动化客户端开发指南

1. 项目概述：基于Chrome扩展网关的LINE消息自动化客户端

如果你正在寻找一种能够绕过官方API限制，直接与LINE服务器进行深度交互的自动化方案，那么2manslkh/line-api这个项目绝对值得你深入研究。它本质上是一个Python客户端库，通过模拟LINE官方Chrome扩展的通信协议，实现了对LINE消息、联系人、群组等核心功能的程序化控制。这个项目的核心价值在于，它提供了一条“非官方”但高度稳定的自动化路径，尤其适合需要批量管理LINE账号、构建自动化客服机器人或进行社交数据聚合分析的开发者。

我最初接触这个项目，是因为一个需要管理多个LINE群组并自动回复特定消息的客户需求。官方提供的Messaging API虽然稳定，但功能受限、审核严格且存在诸多限制（如无法读取历史消息、无法管理联系人列表）。而市面上的一些基于逆向工程的方案又往往过于脆弱，LINE客户端的一次更新就可能导致整个脚本失效。这个项目巧妙地选择了Chrome扩展网关（line-chrome-gw.line-apps.com）作为突破口，这是一个相对稳定且功能完整的接口层，为我们打开了一扇窗。

简单来说，这个项目能让你用代码做到：

• 收发消息：向任何好友或群组发送文本消息，并获取聊天记录。
• 管理社交图谱：获取联系人列表、查询用户资料、添加/删除好友、管理黑名单。
• 操控群组：创建群聊、邀请/踢出成员、修改群设置、处理入群邀请。
• 维护个人状态：更新个人显示名称、状态消息、头像等。
• 实现交互：对消息做出反应（点赞、爱心等）、发送回调查询（Postback）。

整个流程的核心是HMAC签名认证。LINE的网关服务器会对每个请求进行签名验证，而签名的密钥生成算法被封装在一个名为lstm.wasm的WebAssembly模块中。项目通过一个Node.js服务（signer.js）来调用这个WASM模块，为Python客户端的每一个API请求生成合法的X-Hmac请求头。这意味着，虽然我们绕过了官方SDK，但依然遵循了LINE服务器的安全校验规则，从而保证了连接的合法性和相对长期的可用性。

2. 核心架构与工作原理深度解析

2.1 为什么选择Chrome扩展网关？

在深入代码之前，理解“为什么是这个网关”至关重要。LINE为其Chrome浏览器扩展提供了一个专用的网关服务器（line-chrome-gw.line-apps.com）。这个网关的设计初衷是让浏览器扩展能与LINE桌面客户端或移动App进行功能同步和数据交换。与公开的、功能受限的REST API不同，这个网关暴露了近乎完整的LINE内部Thrift服务接口，只是以JSON格式进行了封装。

注意：利用非公开接口存在一定风险。虽然该网关相对稳定，但LINE公司有权随时更改或关闭它。因此，基于此项目的任何生产级应用都必须设计完善的错误处理和降级方案。

项目的架构可以清晰地分为三层：

1. 协议层（WASM HMAC签名器）：这是整个系统的安全基石。lstm.wasm和lstmSandbox.js包含了从访问令牌（Access Token）派生HMAC签名密钥的专有算法。signer.js作为一个常驻的HTTP服务（默认端口18944），接收Python客户端发来的签名请求，调用WASM模块计算签名后返回。
2. 客户端层（Python Client）：LineChromeClient类封装了所有对LINE网关的HTTP调用。它负责构建符合网关预期的JSON请求体，向本地的Node.js签名服务获取X-Hmac头，然后发送请求并处理响应。它将复杂的Thrift协议交互简化为清晰的Python方法调用。
3. 网关与业务层：Python客户端直接与LINE的Chrome扩展网关通信。网关负责将JSON请求转换为内部的Thrift二进制调用，访问LINE的核心服务（如TalkService、ContactService、ChatService等），并将结果再转换回JSON返回。我们完全无需关心Thrift的细节。

2.2 认证流程：QR扫码登录的完整状态机

登录是使用该客户端的第一步，也是最复杂的一步，因为它需要真实用户的交互（扫码和输入PIN）。项目中的QRLogin类实现了一个完整的状态机。

状态机详细步骤与原理：

1. 创建会话（createSession）：客户端向网关发起请求，获取一个唯一的X-Line-Session-ID。这个ID将用于关联后续所有的登录流程请求，是维持登录状态上下文的关键。
2. 生成二维码（createQrCode）：利用上一步的Session ID，请求生成一个二维码。网关返回一个回调URL。这里有一个关键细节：URL需要手动附加?secret={curve25519_pubkey}&e2eeVersion=1参数。curve25519_pubkey是客户端本地生成的一个临时公钥，用于后续可能发生的端到端加密（E2EE）握手。即使你不需要E2EE功能，这个参数也必须提供，它是协议的一部分。
3. 轮询二维码状态（checkQrCodeVerified）：客户端开始以短间隔（例如1秒）轮询网关，查询用户是否已经用手机LINE App扫描了二维码。此请求仅携带X-Line-Session-ID，无需Origin头。一旦扫描成功，轮询停止。
4. 验证证书（verifyCertificate）：这是最容易出错的一步。扫描后，客户端必须调用此接口。即使调用返回失败（例如证书不匹配），这个调用行为本身也是必要的状态转换。它告诉服务器客户端已准备进入下一阶段。如果验证成功，则可能跳过PIN码步骤直接登录；如果失败或未完成，则进入PIN码流程。
5. 生成PIN码（createPinCode）：当证书验证未完成时，网关会生成一个6位数字的PIN码。on_pin回调会立即触发，此时你必须将PIN码在60秒内告知用户，让用户在手机App上输入。这是整个流程中时间最紧迫的环节。
6. 轮询PIN码验证（checkPinCodeVerified）：客户端继续轮询，等待用户在手机上输入PIN码并确认。
7. 最终登录（qrCodeLoginV2）：PIN码验证通过后，调用此接口完成登录。网关返回最终的auth_token（用于后续API调用）、mid（你的用户ID）和refresh_token（用于刷新会话）。

实操心得：

• 证书缓存问题：登录成功后，一个证书文件（sqr_cert）会缓存在本地~/.line-client/目录。下次登录时，如果证书有效，可能会直接登录而跳过PIN码步骤。这在自动化中有时会导致问题，因为你的脚本可能一直在等待一个不会出现的PIN码。因此，在开始一次新的登录流程前，手动删除~/.line-client/sqr_cert文件是一个好习惯。项目提供的qr_login_standalone.py脚本已经内置了这一步。
• PIN码的中继延迟是最大敌人：在自动化部署中，如果你的脚本通过一个网络服务或消息队列来中继PIN码，任何网络延迟或处理延迟都可能消耗掉宝贵的60秒窗口。最佳实践是让生成PIN码的进程直接以最快的方式通知用户，例如写入一个内存文件，由另一个高频轮询的进程立刻读取并发送。

2.3 HMAC签名机制：安全请求的守护者

每个发送到line-chrome-gw.line-apps.com的请求，都必须在头部包含X-Hmac签名。签名的计算方式是：HMAC-SHA256(密钥, 请求路径 + 请求体字符串)，结果进行Base64编码。

关键点在于密钥的生成：密钥并非固定，而是由LINE客户端版本号（如"3.7.1"）和当前的auth_token通过一个自定义的密钥派生函数（KDF）动态生成的。这个KDF的实现就藏在lstm.wasm这个WebAssembly二进制文件中。WASM的使用使得逆向工程和动态分析变得困难，保护了算法的机密性。

项目提供了两种签名模式：

• 服务器模式（Server Mode）：启动一个Node.js HTTP服务器（signer.js）。Python客户端通过HTTP请求将待签名的数据发送到localhost:18944，由Node.js调用WASM计算后返回签名。延迟极低（~13ms），是推荐的生产模式。
• 子进程模式（Subprocess Mode）：作为备选方案，每次签名都启动一个Node.js子进程来执行计算。延迟很高（~2秒），仅用于调试或服务器模式失败时。

配置要点：确保你的环境能正确运行Node.js，并且lstm.wasm和lstmSandbox.js文件存在于项目根目录或Node.js服务能找到的路径。签名服务启动失败会导致所有API调用异常。

3. 环境部署与快速上手实操指南

3.1 系统环境与依赖安装

假设你在一台干净的Ubuntu 22.04服务器上部署。我们选择使用系统包管理器安装Python依赖，这通常比pip更干净，避免版本冲突。

# 1. 更新系统并安装基础工具和Node.js sudo apt-get update sudo apt-get install -y python3 python3-pip nodejs npm wget git # 2. 安装项目所需的Python系统包 # 这些包提供了核心的加密、网络和图像处理功能 sudo apt-get install -y python3-requests python3-qrcode python3-pil python3-nacl python3-cryptography python3-httpx python3-rsa # 3. 安装pycryptodome，这是一个强大的密码学工具包 sudo apt-get install -y python3-pycryptodome # 4. 处理潜在的模块名冲突 # pycryptodome在某些系统上会安装为`Cryptodome`，但老代码可能导入`Crypto` if [ ! -d "/usr/lib/python3/dist-packages/Crypto" ] && [ -d "/usr/lib/python3/dist-packages/Cryptodome" ]; then sudo ln -sf /usr/lib/python3/dist-packages/Cryptodome /usr/lib/python3/dist-packages/Crypto echo "已创建 Crypto 符号链接。" fi

3.2 获取项目代码与启动签名服务

# 1. 克隆仓库 git clone https://github.com/2manslkh/line-api.git cd line-api # 2. 确保WASM文件存在（它们是签名所必需的） ls -la lstm.wasm lstmSandbox.js # 如果不存在，你需要从项目Release或源码中找回这两个文件。 # 3. 启动HMAC签名服务器（后台运行） node src/hmac/signer.js serve > signer.log 2>&1 & SIGNER_PID=$! echo "签名服务已启动，PID: $SIGNER_PID" # 4. 验证签名服务是否运行 sleep 2 curl -s http://localhost:18944/health # 应该返回 `{"status":"ok"}` # 5. (可选) 安装Python项目本身的依赖（如果需要） # 通常项目设计为使用系统包，但检查一下requirements.txt if [ -f "requirements.txt" ]; then pip3 install -r requirements.txt fi

3.3 执行QR扫码登录并获取令牌

登录是交互式的。对于自动化场景，项目提供了qr_login_standalone.py脚本，它将QR码和PIN码写入文件，方便外部程序读取。

# 1. 确保清理旧的证书缓存，强制走完整PIN码流程，便于自动化 rm -f ~/.line-client/sqr_cert # 2. 在后台运行独立登录脚本 python3 scripts/qr_login_standalone.py & LOGIN_PID=$! echo "登录脚本已启动，PID: $LOGIN_PID" # 3. 监控状态文件，等待QR码生成 QR_STATUS_FILE="/data/workspace/line_status.txt" # 脚本默认路径，可根据实际情况调整 while [ ! -f "$QR_STATUS_FILE" ] || ! grep -q "QR_READY" "$QR_STATUS_FILE"; do echo "等待QR码生成..." sleep 1 done # 4. QR码已生成，图片路径在 /data/workspace/line_qr.png # 你需要将此图片发送给用户（例如，通过邮件、消息推送或显示在Web界面） QR_IMAGE="/data/workspace/line_qr.png" echo "QR码已生成: $QR_IMAGE" # 此处添加你的代码，将图片发送给用户... # 5. 高频轮询，等待PIN码出现（时间紧迫！） PIN_FILE="/data/workspace/line_pin.txt" while [ ! -f "$PIN_FILE" ]; do sleep 0.2 # 以0.2秒为间隔高频检查，争分夺秒 done PIN_CODE=$(cat "$PIN_FILE") echo "获取到PIN码: $PIN_CODE - 必须在60秒内发送给用户！" # 立刻！马上！将 $PIN_CODE 发送给用户输入！ # 6. 等待登录完成 DONE_FILE="/data/workspace/line_done.txt" while [ ! -f "$DONE_FILE" ]; do sleep 2 done RESULT=$(cat "$DONE_FILE") if [[ $RESULT == OK:* ]]; then MID=${RESULT#OK:} echo "登录成功！用户MID: $MID" echo "令牌已保存至 ~/.line-client/tokens.json" else echo "登录失败: $RESULT" exit 1 fi

登录成功后，你的访问令牌、刷新令牌等信息会以JSON格式保存在~/.line-client/tokens.json。主客户端LineChromeClient就是通过读取这个文件来初始化的。

3.4 编写第一个自动化脚本

现在，你可以编写Python脚本使用获取到的令牌进行自动化操作了。

import json from pathlib import Path from src.chrome_client import LineChromeClient, APIError # 1. 加载令牌 token_path = Path.home() / ".line-client" / "tokens.json" try: with open(token_path, 'r') as f: tokens = json.load(f) auth_token = tokens.get("auth_token") if not auth_token: raise ValueError("在 tokens.json 中未找到 auth_token") except FileNotFoundError: print("令牌文件不存在，请先运行QR登录。") exit(1) # 2. 初始化客户端 client = LineChromeClient(auth_token=auth_token) # 3. 获取自己的个人信息 try: my_profile = client.get_profile() print(f"登录账号: {my_profile.get('displayName')} (MID: {my_profile.get('mid')})") print(f"状态消息: {my_profile.get('statusMessage')}") except APIError as e: print(f"获取资料失败，错误码 {e.code}: {e.api_message}") if e.code == 10051: # Token过期 print("令牌已过期，请重新登录。") exit(1) # 4. 获取所有联系人的MID try: all_friend_mids = client.get_all_contact_ids() print(f"共有 {len(all_friend_mids)} 位好友。") except APIError as e: print(f"获取联系人列表失败: {e}") # 5. 向特定好友发送消息（示例，请替换为真实的MID） target_mid = "Uxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 替换为好友的MID message_text = "你好，这是一条来自自动化客户端的测试消息。" try: # 重要：发送前检查是否为E2EE聊天（群组） if client.is_e2ee_chat(target_mid): print(f"警告：聊天 {target_mid} 已启用端到端加密，当前无法通过此客户端发送消息。") else: client.send_message(target_mid, message_text) print(f"消息已发送至 {target_mid}。") except APIError as e: print(f"发送消息失败，错误码 {e.code}: {e.api_message}") # 6. 获取最近聊天的列表（类似LINE首页） try: recent_chats = client.get_message_boxes(count=20) for chat in recent_chats: chat_id = chat.get('id') last_msg = chat.get('lastMessage', {}) print(f"聊天ID: {chat_id}, 最后消息: {last_msg.get('text', '[非文本或加密]')[:50]}...") except APIError as e: print(f"获取最近聊天失败: {e}")

4. 核心功能详解与高级使用技巧

4.1 消息收发与聊天管理

send_message是最常用的功能，但有一些细节需要注意。

参数详解：

client.send_message( to="U...或C...", # 收件人MID text="消息内容", content_metadata=None, # 高级内容元数据（如图片、链接预览） content_preview=None, # 内容预览 related_message_id=None, # 关联消息ID reply_to="消息ID", # **回复某条消息**，这是实现回复功能的关键参数 message_type=1, # 1: 文本消息 (默认) )

实现回复功能：将reply_to参数设置为目标消息的id字段，发送的消息就会成为一条回复。这在构建客服机器人或进行对话管理时非常有用。

获取消息历史：get_recent_messages和get_previous_messages用于分页获取历史消息。后者需要传入end_seq（上一条消息的序列号）来获取更早的消息。

# 获取某个聊天最近的50条消息 recent = client.get_recent_messages("C...", count=50) if recent: last_seq = recent[-1].get('seq') # 获取最后一条消息的序列号 # 获取更早的50条 older = client.get_previous_messages("C...", end_seq=last_seq, count=50)

标记已读与删除聊天：

• send_chat_checked(chat_id, last_message_id)：将某个聊天标记为已读。需要传入该聊天中最后一条已读消息的ID。这会影响LINE客户端上的未读红点。
• send_chat_removed(chat_id, last_message_id)：将聊天从聊天列表中移除（归档）。它不会删除消息，只是在当前设备上隐藏。

4.2 联系人与群组操作

查找与添加好友：

# 通过LINE ID查找用户（对方设置了ID才能查到） search_result = client.find_contact_by_userid("朋友的LINE_ID") if search_result: found_mid = search_result[0].get('mid') # 尝试添加好友 client.add_friend_by_mid(found_mid) # 或者使用 RelationService 的添加方式 # client.find_and_add_contact_by_mid(found_mid) # 通过手机号查找（需要对方绑定了手机号且隐私设置允许） phone_results = client.find_contacts_by_phone(["+8613800138000"])

群组管理：

# 1. 创建群组 new_chat_id = client.create_chat("我们的项目群", ["Ufriend1", "Ufriend2"]) print(f"新群组创建成功，ID: {new_chat_id}") # 2. 邀请更多人加入 client.invite_into_chat(new_chat_id, ["Ufriend3", "Ufriend4"]) # 3. 获取群组详情（包含成员列表） chat_details = client.get_chats([new_chat_id], with_members=True) members = chat_details[0].get('members', []) print(f"群成员: {[m.get('displayName') for m in members]}") # 4. 更新群组名称 client.update_chat(new_chat_id, {"name": "更名为：核心项目组"}) # 5. 将群组归档（隐藏） client.set_chat_hidden_status(new_chat_id, hidden=True)

4.3 事件监听与实时消息处理

对于需要实时响应的机器人应用，轮询（Polling）是核心机制。客户端提供了poll()生成器和on_message装饰器两种方式。

使用poll()生成器（手动控制）：

import time from src.chrome_client import OpType # 需要导入操作类型常量 def manual_polling_example(client): """手动轮询示例，灵活性高""" try: for op in client.poll(): # poll() 是一个无限循环的生成器 op_type = op.get('type') if op_type == OpType.RECEIVE_MESSAGE: # 27: 收到新消息 msg = op.get('message', {}) chat_id = msg.get('to') sender_mid = msg.get('from') text = msg.get('text', '') # 注意：E2EE群组的消息text为空，内容在`chunks`字段 print(f"[新消息] 来自 {sender_mid} 在 {chat_id}: {text[:100]}") # 在此处添加你的自动回复逻辑 # if text == "ping": # client.send_message(chat_id, "pong") elif op_type == OpType.SEND_MESSAGE: # 26: 自己发送的消息同步 print(f"[发送同步] 消息已送达服务器。") elif op_type == OpType.NOTIFIED_READ_MESSAGE: # 55: 消息被对方已读 print(f"[已读回执] 消息已被阅读。") # 可以处理其他类型的Op，如联系人更新、群组变动等 except KeyboardInterrupt: print("轮询停止。") except APIError as e: print(f"轮询过程中出错: {e}")

使用on_message装饰器（自动后台线程）：

from threading import Event stop_event = Event() @client.on_message def handle_new_message(message, client_instance): """当收到新消息时，此函数会被自动调用（在后台线程中）""" # 注意：参数是 (message, client) chat_id = message.get('to') text = message.get('text', '').strip().lower() # 简单的关键词回复示例 if text == '帮助': client_instance.send_message(chat_id, "可用命令：\\n1. 状态\\n2. 时间") elif text == '状态': profile = client_instance.get_profile() client_instance.send_message(chat_id, f"我在线，我是{profile.get('displayName')}。") elif text == '时间': server_time = client_instance.get_server_time() client_instance.send_message(chat_id, f"服务器时间: {server_time}") # 启动后台轮询线程 client.start() # 这会启动一个守护线程，持续调用 poll() 并触发 handle_new_message # 主程序可以去做其他事情... print("机器人已启动，正在监听消息...") try: # 例如，等待一个停止信号 while True: time.sleep(1) except KeyboardInterrupt: print("正在停止机器人...") client.stop() # 停止轮询线程 stop_event.set()

重要提醒：on_message处理函数是在后台线程中被调用的。确保你的处理逻辑是线程安全的，如果涉及共享资源，需要加锁。同时，处理函数应尽可能高效，避免长时间阻塞，否则会影响消息接收的实时性。

5. 端到端加密（E2EE）的挑战与应对策略

这是当前项目最大的功能限制，也是在实际使用中最容易踩坑的地方。

5.1 识别E2EE聊天

在发送消息前，必须使用client.is_e2ee_chat(chat_id)进行检查。对于返回True的聊天（通常是启用了“聊天锁定”或“私密聊天”的群组），send_message接口会失败，并返回错误码82（“types mismatch”）。

如何判断一个群组是否启用了E2EE？

1. 主动检查：调用is_e2ee_chat。
2. 被动识别：当你从get_recent_messages获取消息时，E2EE聊天中的消息体结构不同。普通消息的文本在text字段，而E2EE消息的文本被加密后存放在chunks字段，text字段为空或不存在。

   messages = client.get_recent_messages(some_chat_id, count=5) for msg in messages: if 'chunks' in msg and msg['chunks']: print("这条消息来自E2EE聊天，内容已加密。") # msg['text'] 可能为空或不存在 else: print(f"普通消息: {msg.get('text')}")

5.2 当前限制与根本原因

项目中的src/e2ee/crypto.py文件表明开发者已经部分实现了E2EE的加密解密逻辑（基于Curve25519密钥交换和AES-GCM加密）。然而，该模块尚未与send_message功能集成。

根本原因在于E2EE v2协议的复杂性：

1. 群组密钥管理：在E2EE群组中，每条消息都需要使用一个“发送链密钥”加密，而这个密钥需要与群内每个成员的长期公钥进行密钥协商后派生出来。
2. 密钥轮换：为了前向保密，发送链密钥会随着消息发送而不断更新，需要维护状态。
3. 服务器不参与解密：LINE服务器只能看到加密后的密文（chunks），无法解密。客户端必须自己完成所有的加密解密操作。

因此，实现完整的E2EE消息发送，需要：

• 获取群组所有成员的Curve25519公钥。
• 为每个成员分别进行ECDH密钥协商，生成共享密钥。
• 使用共享密钥派生出一个对称密钥，用于加密消息。
• 将加密后的消息打包成特定的chunks格式。
• 在本地维护每个E2EE聊天的发送链密钥状态。

这是一个相当复杂的密码学工程，目前项目尚未完成。

5.3 可行的替代方案与建议

如果你的自动化场景必须处理E2EE群组，可以考虑以下变通方案：

1. 降级群组加密：引导群主或成员在LINE App的群设置中关闭“聊天锁定”或“私密聊天”功能。这会将群组降级为普通群组，即可正常使用API。但这违背了用户的加密意愿。
2. 使用LINE Official Account API：如果你有官方账号，可以通过官方提供的Messaging API向用户发送消息。但此API功能有限，且无法读取群组消息或管理非官方账号的社交关系。
3. 混合模式处理：在你的机器人逻辑中，对E2EE聊天进行特殊处理。例如，当检测到消息来自E2EE聊天时，自动回复一条提示：“本机器人无法在加密群组中工作，请将我移至普通群组或通过私聊联系。”
4. 关注项目进展：密切关注原仓库的更新。E2EE支持是很多用户期待的功能，未来可能会被实现。

6. 常见问题排查与稳定性优化

在实际部署和长期运行中，你会遇到各种问题。以下是我在实践中总结的常见问题与解决方案。

6.1 错误码速查与处理

通用的错误处理模式：

from src.chrome_client import APIError import time def safe_api_call(client, api_func, *args, retries=3, **kwargs): """带重试机制的API调用封装""" for i in range(retries): try: return api_func(*args, **kwargs) except APIError as e: if e.code == 10051: print("令牌过期，无法通过重试解决，需要重新登录。") raise # 重新抛出，让上层处理登录更新 elif e.code in [10052, 8]: # 可重试的错误 wait = (i + 1) * 2 # 指数退避 print(f"遇到错误 {e.code}, {e.api_message}。第{i+1}次重试，等待{wait}秒...") time.sleep(wait) continue else: # 其他错误，如参数错误，重试无用 print(f"API调用失败，错误码 {e.code}: {e.api_message}") raise print(f"重试{retries}次后仍失败。") raise Exception("API调用最终失败") # 使用示例 try: profile = safe_api_call(client, client.get_profile) except Exception as e: # 处理最终失败或令牌过期 print(f"操作失败: {e}")

6.2 稳定性与性能优化建议

1. 令牌管理自动化：

   • 不要硬编码令牌。始终从~/.line-client/tokens.json动态读取。
   • 编写一个监控脚本，定期（例如每天）检查令牌是否即将过期（可以通过调用一个简单API如get_profile来测试），并自动触发重新登录流程。qr_login_standalone.py脚本非常适合集成到此类自动化流程中。

2. 签名服务高可用：

   • signer.js服务是关键单点。在生产环境，可以将其包装为一个系统服务（如使用systemd），并设置自动重启。

   # 示例 systemd 服务文件 /etc/systemd/system/line-hmac-signer.service # [Unit] # Description=LINE HMAC Signer Service # After=network.target # # [Service] # Type=simple # User=your_user # WorkingDirectory=/path/to/line-api # ExecStart=/usr/bin/node src/hmac/signer.js serve # Restart=on-failure # RestartSec=5 # # [Install] # WantedBy=multi-user.target

   • 在Python客户端中，可以增加对签名服务健康检查的逻辑，如果连接失败，尝试重启服务或报警。

3. 请求频率控制：

   • 避免在短时间内发起大量API请求，这可能会触发LINE的频率限制或导致IP暂时被封。在循环操作（如向所有好友发送消息）中加入适当的延迟（例如time.sleep(0.5)）。
   • 使用try-except捕获异常，并在遇到频率限制错误时采用指数退避策略进行重试。

4. 状态与缓存：

   • 对于不常变化的数据，如联系人列表、群组信息，可以在本地进行缓存，定期更新，而不是每次需要时都调用API。
   • 维护一个本地的last_op_revision，这是LINE服务器用于同步的事件流水号。在调用fetch_ops或启动poll时，可以传入这个版本号来获取错过的操作，保证事件不丢失。

5. 日志与监控：

   • 为你的机器人应用添加详细的日志记录，记录每一条消息的收发、每一个API调用及其结果。这对于调试和事后分析至关重要。
   • 监控关键指标：消息发送成功率、API错误率、令牌有效期、签名服务状态等。

6.3 部署与多账号管理

如果你需要管理多个LINE账号，需要隔离每个账号的环境。

1. 目录隔离：每个账号应有独立的配置目录。可以通过环境变量或命令行参数指定~/.line-client的路径。

   # 账号A export LINE_CLIENT_HOME=/path/to/account_a_config python3 my_bot.py # 账号B export LINE_CLIENT_HOME=/path/to/account_b_config python3 my_bot.py

   在代码中：

   import os config_home = os.environ.get('LINE_CLIENT_HOME', os.path.expanduser('~/.line-client')) token_path = Path(config_home) / 'tokens.json'

2. 进程隔离：为每个账号运行独立的Python进程和Node.js签名服务进程，并绑定到不同的端口（通过修改signer.js的端口或使用不同的HMAC_SIGNER_URL环境变量）。

   # 在初始化客户端时指定签名服务地址 signer_url = os.environ.get('HMAC_SIGNER_URL', 'http://localhost:18944') client = LineChromeClient(auth_token=auth_token, signer_url=signer_url)

3. 资源管理：确保服务器有足够的内存和CPU资源来运行多个签名服务实例和Python机器人实例。