企业官网建设流程全解析

最近一直在折腾内部效率工具，其中一个需求就是把手头的飞书和腾讯会议串起来。公司里飞书管协作、腾讯会议管线上音视频，每天开会的人在群里发会议号、复制链接，约一场会要来回改好几轮，散会之后纪要又经常散落在各个文档里找不着。于是我们做了个小项目：在飞书群里输一条命令，机器人自动调腾讯会议API把会建好，入会信息和会议链接直接回传到群里；会议结束之后，通过回调把录制链接、纪要材料自动归档到飞书云文档。整个过程跑下来，最大的感触是：开放平台之间的对接本身不复杂，真正卡人的全是权限、Token、回调验签这些细节。这篇文章把从零到一的完整实践过程写出来，包含配置步骤、核心代码和踩坑记录，适合正在做飞书或腾讯会议二次集成的同学参考。

1. 对接前先把场景想清楚：飞书和腾讯会议到底能怎么玩

1.1 90%的团队需要的是这三条链路

在动手之前，先花一天时间把实际使用场景理清楚，比直接去翻API文档重要得多。我们调研完同事的反馈，发现日常开会最痛的点基本集中在三条链路：

第一条是一键建会。以前在飞书群里约会议，靠人工把会议主题、时间、参会人整理好，再去腾讯会议客户端里创建一个会议，然后把会议号、入会链接复制回群。整个过程重复性极高，还容易漏人。现在做的是在飞书群里@机器人，输入“开会 主题 时间”，机器人直接调腾讯会议API把预定会议建好，返回一个富文本卡片，成员点卡片里的链接就能入会。

第二条是会议信息同步。会议一旦建好，会议号、入会链接、会议时间、创建人这些信息都要在飞书侧留痕。用飞书消息卡片承载会变得非常直观——卡片上把会议主题、开始时间、腾讯会议链接都排好版，比纯文本消息清楚得多。这里牵扯到飞书消息API和卡片JSON的组装。

第三条是会议结束后的自动归档。腾讯会议支持配置会议结束事件的回调，会议结束后我们把会议录制地址、参会人列表、会议开始结束时间这些信息抽出来，调用飞书云文档API写进一份归档文档里，再在群里发一条“会议纪要已归档”的卡片通知。这一条最受leader欢迎，因为周会、复盘会的资料终于不用再手动整理了。

除了这三条，还有一些高阶玩法，比如在飞书审批通过后自动创建腾讯会议，或者用飞书多维表格记录所有会议台账。但这些都建立在基础链路跑通的基础上，前期不建议一上来就全做。

1.2 技术路线选型：自建应用还是Webhook机器人

很多第一次接触这类对接的朋友会纠结一个问题：飞书那边到底应该用“群自定义机器人”还是“企业自建应用”？这个选择直接决定后面能做多少事情。

飞书的群自定义机器人（Webhook机器人）使用门槛极低，在群里添加一个机器人，拿到Webhook地址，用POST发一串JSON就能向群里推消息。但它只能“发”，不能“收”，也没法调用飞书开放平台上的API，更拿不到事件回调。也就是说，用Webhook机器人做单向通知没问题，像每天定时推送会议提醒、日报汇总，够用；但要做“用户在群里发指令，机器人去腾讯会议建会”这种双向交互，就完全不够了。

企业自建应用才是完整对接的正路。创建应用后拿到App ID和App Secret，既可以用机器人身份发消息，也能订阅飞书事件（比如收到消息事件、审批通过事件），还能调用通讯录、云文档、日历等API。缺点就是配置环节多一些，权限申请要走一遍审核。不过一旦跑通，后面的扩展空间完全不在一个量级。

腾讯会议侧其实没有太多选择余地，它就是一套标准REST API加回调事件。要对接就得去腾讯会议开放平台注册应用，拿到身份凭证。注意腾讯会议的开放接口一般需要企业版账号才有接口权限，个人免费版基本调不了API，这个在立项前就要跟管理员确认清楚。

1.3 对接方案的整体架构

我把整个系统的数据流描述为：飞书负责“入口”和“出口”，腾讯会议负责“会议本体”，中间用一个自己的后端服务做翻译和搬运。

用户在飞书群里输入的消息，通过飞书事件订阅推送给我们部署在后端的服务。后端解析出意图和参数，带着用户的身份发起创建会议请求到腾讯会议的REST API。腾讯会议返回会议号和入会链接后，后端再调用飞书消息API，组装一张会议卡片发回群里。会议结束的那一刻，腾讯会议把结束事件POST到我们配置的回调地址，后端拿到事件后去拉取会议详情和录制文件信息，再调飞书云文档API把结构化内容写入文档。

整个链路里，飞书侧我们用了一个自建应用，后端服务起了Flask（后面会上Python代码），腾讯会议侧就是一个标准企业应用。服务部署在普通云服务器上就行，唯一的要求是公网可访问，或者至少能用长连接方式收发飞书事件。如果没有公网IP，飞书事件订阅可以用长连接（WebSocket）代替Webhook回调，这招对于个人开发者和内网部署特别友好，后面会具体讲。

2. 飞书侧准备：应用创建、权限申请与Token体系

2.1 创建企业自建应用并开通权限

飞书侧的准备工作，核心是在飞书开放平台（open.feishu.cn）上创建一个“企业自建应用”。登录管理员账号后，进入开发者后台，选择创建企业自建应用，填上应用名称和描述，然后进入应用详情页。

创建完成之后，首先要做的是在“应用能力”里添加一个“机器人”能力。很多初学者会忽略这一步，后面调用消息API的时候报“bot not found”之类的错误，其实就是因为应用没有启用机器人能力。启用了机器人之后，应用在飞书里就有了一个机器人身份，可以被添加到群聊里，也才能以机器人身份发送消息。

接下来是权限管理，这是飞书开放平台上最容易绕晕的地方。飞书的权限控制做得非常细，应用每调用一类资源，都需要申请对应的权限点。比如你要在群里发消息，需要申请“获取与发送单聊、群组消息”权限（im:message）和“以应用的身份发消息”权限（im:message:send_as_bot）；要读写云文档，需要申请“查看、评论、编辑和管理云文档”权限（docx:document）和“查看、评论、编辑和管理云空间文件”权限（drive:drive）；要读取用户发给机器人的消息内容，需要申请“接收群聊中@机器人消息事件”权限（im:message.group_at_msg）和“接收用户发给机器人的单聊消息事件”权限（im:message.p2p_msg）。

权限申请提交之后，不是马上生效的。飞书的机制是：修改完权限配置后，需要创建应用版本并发布，等企业管理员在管理后台审核通过，新增的权限才会真正生效。这个点经常坑到人——本地调试时调一个接口返回权限不足，查半天发现是应用版本没有重新发布。所以建议流程是：先一次性把可能用到的权限都申请好，再发布版本，避免来回折腾。

2.2 理解两套Token：tenant_access_token与user_access_token

飞书的Token体系是新手最容易卡住的地方。它有两套凭证，虽然都叫Token，但使用场景和权限边界完全不同。

第一套叫tenant_access_token，意思是“应用身份凭证”，代表“这个应用”在飞书里的身份。你用App ID和App Secret调用一个固定的接口（POST /open-apis/auth/v3/tenant_access_token/internal）就可以获取。拿到它之后，可以用应用的身份发消息、建文档、读通讯录。它的有效期是两小时，过期后需要重新获取。

第二套叫user_access_token，意思是“用户身份凭证”，代表“某个具体的用户在授权之后”授予应用的临时通行证。这套Token的获取要复杂一些，需要走OAuth流程：先在浏览器里打开一个授权链接让用户登录同意，腾讯返回一个授权码，用授权码换Token。用户身份Token能访问用户私有空间的数据，比如用户自己的云文档、多维表格记录，很多文档类接口必须用它才能调通。

结合本文场景，如果你只是想用机器人往群里推会议卡片，tenant_access_token就够了。但如果你要做“会议纪要写进某个用户的云文档”这种操作，大概率需要user_access_token。很多人第一次配置Dify这类AI工具访问飞书云文档时，卡在授权凭证上拿不到数据，本质就是没搞明白：以用户身份去开别人的文档，必须走OAuth拿到用户的Token，而不是拿一个应用身份的Token硬闯。

获取tenant_access_token的Python代码非常简单，如下：

import requests def get_tenant_access_token(app_id: str, app_secret: str) -> str: url = "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal" payload = { "app_id": app_id, "app_secret": app_secret } resp = requests.post(url, json=payload, timeout=5) data = resp.json() if data.get("code") != 0: raise RuntimeError(f"获取tenant_access_token失败: {data}") return data["tenant_access_token"]

这个Token建议做缓存，不要每次请求都重新获取。飞书侧对获取Token的接口有限流，短期频繁调用会直接报错。实际操作中，我用了一个内存字典加过期时间，或者直接存Redis，逻辑很简单：距离过期时间还剩5分钟时就主动刷新。

2.3 事件订阅接入方式：长连接优先，Webhook兜底

飞书把用户消息推给我们后端服务，靠的是“事件订阅”机制。在自建应用的“事件与回调”页面里，可以添加事件类型，比如“接收消息”事件（im.message.receive_v1）。添加之后，飞书会在消息发生时把事件内容推送到我们配置的地址。

这里有一个非常重要的选择：Webhook方式和长连接（WebSocket）方式。

Webhook方式要求你有一个公网可访问的HTTPS地址，飞书会把事件POST到这个地址。它的优点是稳定、可控，适合生产环境；缺点是你得有一台能暴露公网的服务器，还要配置域名和证书，开发调试阶段比较麻烦。

长连接方式就不需要公网回调地址。飞书自建应用的事件订阅里，有一个“使用长连接接收事件”的选项，启用后，用飞书官方SDK在你的后端服务里跑一个WebSocket客户端，飞书会主动建立连接往下推事件。这种方式对本地开发、内网部署特别友好，开发和测试阶段几乎零成本，我自己在项目前期就是靠这个方式把流程跑通的。

配置长连接也很简单，飞书官方提供了Python SDK（lark-oapi），核心代码大致是：

from lark_oapi.ws import Client as WSClient def handle_message(data): # 处理收到的消息事件 print(data) ws_client = WSClient( app_id="your_app_id", app_secret="your_app_secret", event_handler=handle_message, ) ws_client.start()

需要注意，无论Webhook还是长连接，如果启用了加密（Encrypt Key），推送过来的事件内容就是加密的。长连接模式下SDK会帮忙解密，Webhook模式就需要自己处理解密逻辑。我在项目里用了一个简单的AES解密函数来解开飞书的加密报文，逻辑不复杂，但拼错一个Key或初始向量就会全盘乱码，这个后面排查章节会专门讲。

3. 腾讯会议侧准备：开发者认证、应用创建与鉴权签名

3.1 开启开发者权限并创建应用

腾讯会议开放平台的准备工作和飞书侧大同小异，但有一个门槛要提前确认：腾讯会议开放API目前主要面向企业版和商业版的用户开放，个人免费版账号大概率申请不到接口权限。所以第一步不是写代码，而是先让企业管理员确认自己所在的企业版套餐是否包含“开放平台”权限，如果不包含，需要先联系商务开通，不然应用创建页面都进不去。

确认之后，登录腾讯会议开放平台（meeting.tencent.com的开发者板块或者企业管理员后台），创建一个企业级应用。创建成功后，开放平台会给你生成一串关键凭证：App ID（也叫Secret ID）和App Secret（也叫Secret Key）。这两个值后面调用API时做签名要用，务必妥善保存，不要硬编码到前端代码或者提交到Git仓库里。

腾讯会议开放平台的应用不像飞书那样区分“企业自建应用”和“商店应用”，它就是个单纯的应用凭证。你需要重点关注的是应用权限范围。有的企业会限制应用只能调用某些API，比如只允许创建会议、不允许修改会议或获取录制文件。申请应用之后，对照你的需求清单，在开放平台里把你的应用权限勾选完整。

3.2 腾讯会议API的鉴权原理与签名计算

腾讯会议的API鉴权和飞书不太一样，飞书是一个Authorization: Bearer <token>搞定，腾讯会议要求请求头里带一堆自定义Header，还要做一次SHA256签名。

我用的版本要求这些Header：

• X-TC-Key：应用的App ID。
• X-TC-Nonce：随机字符串，每次请求都不同，用来防重放攻击。
• X-TC-Timestamp：发起请求的Unix时间戳，单位是秒。
• X-TC-Signature：签名值，具体算法是把app_id + timestamp + nonce + secret_key按固定顺序拼接之后做SHA256，再转成十六进制字符串。
• Authorization: Bearer <userid>：这个Header写的是调用者对应的腾讯会议用户ID（一般是企业里的某个成员），腾讯会议API会把这个请求看作是该成员发起的操作。

签名串拼接顺序这一点，谨记以你当前版本开放平台文档为准。我一开始就是照着一个老版本的博客文章写的，结果签名一直验证失败，后来才发现新版要求的拼接顺序里timestamp和nonce换了位置。所以最稳妥的做法是到你自己的开放平台应用详情页里，找到“接口鉴权说明”或者“签名算法”文档，对照着拼一遍。

如果签名计算正确，构造请求头就会像下面这样：

import hashlib import time import random import string import requests def build_headers(app_id: str, app_secret: str, user_id: str): timestamp = str(int(time.time())) nonce = ''.join(random.choices(string.ascii_letters + string.digits, k=8)) raw = f"{app_id}{timestamp}{nonce}{app_secret}" signature = hashlib.sha256(raw.encode("utf-8")).hexdigest() return { "X-TC-Key": app_id, "X-TC-Nonce": nonce, "X-TC-Timestamp": timestamp, "X-TC-Signature": signature, "Authorization": f"Bearer {user_id}", "Content-Type": "application/json", }

每个请求头缺一不可，Content-Type漏掉会导致接口返回415。另外注意时间戳一定要用服务器当前时间，误差太大容易被拒绝；nonce每次请求都要重新生成，如果复用同一个nonce，腾讯会议服务器会认为是重复请求直接拒绝。

3.3 回调事件配置：验证与解密

腾讯会议的会议结束事件、创建事件等都是通过回调通知来推送的。在开放平台的应用配置页里，有一个“回调地址”的配置项。配置完成后，腾讯会议会立刻发一个验证请求到你的地址，你需要按规定的格式返回，验证才算通过。

这个验证机制很多第一次对接的人会卡住。腾讯会议回调的验证流程大体是：腾讯会议POST一个JSON到你的回调地址，JSON里包含一个check_value字段或者一个加密后的验证串，你的回调服务收到后，需要按文档要求解密并算出一个respond_value返回给腾讯会议，腾讯会议确认无误之后才会把验证置为成功。

如果配置了加密（推荐开启），回调事件的body就是一个AES加密串。我实际使用的解密过程是：先用Base64解码密文，再用AES-ECB模式，密钥取应用的Secret Key（注意对齐长度），最后得到JSON明文。解出来的内容类似：

{ "event_type": "meeting.ended", "meeting_id": "1234567890", "meeting_info": { "meeting_code": "123456789", "subject": "周会", "start_time": "1621044000", "end_time": "1621047600", "host_user_id": "host001", ... } }

这里有一个经验：腾讯会议的Webhook回调对响应时间要求比较紧，建议回调服务收到请求后先立刻返回约定响应，再异步去处理业务逻辑（比如拉取录制文件、写飞书文档）。如果同步处理耗时超过几秒，腾讯会议那边可能直接判定回调失败，之后的重试策略也会让人头疼。我在实际项目里把回调处理放进了一个任务队列，响应速度稳定在500毫秒以内，效果很好。

4. 核心功能实现：在飞书里发起会议，在文档里沉淀纪要

4.1 飞书机器人接收命令并创建腾讯会议

场景打通之后，核心功能的实现就顺理成章了。我先说最常用的一条：用户或群成员给飞书机器人发一条消息，机器人解析出会议主题和时间，然后去腾讯会议创建预定会议。

在飞书事件订阅里，我订阅了im.message.receive_v1事件。在后端收到消息事件之后，先判断聊天类型是单聊还是群聊，然后取event.message.content字段里的文本内容。飞书推送的文本消息content其实是一段JSON字符串，里面有一个text字段才是真正的消息文本。解析之后，用正则或者简单的关键词匹配识别出会议主题和时间。比如我定义了命令格式：/book 周会 2025-06-20 15:00。解析出主题和时间之后，把时间字符串转成UTC时间戳，然后调用腾讯会议的创建会议接口。

腾讯会议创建会议的API是POST /v1/meetings，请求体里核心字段有：

• meeting_info_list：会议信息列表，一次可以创建多个会议。我们场景里一次只创建一个。
• subject：会议主题。
• type：会议类型，0表示立即会议，1表示预定会议。我们这里用1。
• start_time：会议开始时间的Unix时间戳（秒）。注意一定要转成UTC时间，腾讯会议API是按照UTC时间戳来理解的。我曾经直接把本地时间的datetime.timestamp()传过去，结果会议开始时间整整错了8个小时。
• duration：会议时长，单位分钟。
• media_type：媒体类型，1代表视频会议。
• settings：一些会议设置，比如入会是否静音、是否允许成员发言等。

创建成功的返回里，有两个关键字段：meeting_id是会议的唯一ID（后面查详情、拉录制都靠它），meeting_code是9位或10位的入会号码，join_url是入会链接。把它们存下来备用。

4.2 会议信息卡片回传与入会引导

拿到腾讯会议返回的会议信息之后，下一步就是把信息组装成一张飞书消息卡片发回给用户或群。

飞书消息接口是POST /open-apis/im/v1/messages，receive_id_type可以是open_id、user_id、chat_id等。单聊场景，用用户的open_id当接收人；群聊场景，用群的chat_id。msg_type我用的是interactive，也就是消息卡片，卡片内容是一段JSON。

卡片JSON里，我用了一个div模块放会议主题和时间，一个link模块放入会链接，再把meeting_code用醒目字号展示出来。一个精简版卡片大概是这样的：

{ "msg_type": "interactive", "receive_id": "oc_xxxxxxxxxxxx", "content": "{\"config\":{\"wide_screen_mode\":true},\"header\":{\"title\":{\"tag\":\"plain_text\",\"content\":\"会议预约成功\"}},\"elements\":[{\"tag\":\"div\",\"text\":{\"tag\":\"lark_md\",\"content\":\"**主题**：周会\\n**时间**：2025-06-20 15:00\\n**会议号**：**123456789**\"}},{\"tag\":\"action\",\"actions\":[{\"tag\":\"button\",\"text\":{\"tag\":\"plain_text\",\"content\":\"点击入会\"},\"type\":\"primary\",\"url\":\"https://meeting.tencent.com/dm/xxxx\"}]}]}" }

这里有一个细节：content字段是一个字符串，里面嵌套了JSON，所以外层要用json.dumps把字典转成字符串。很多同学第一次写这个接口会忘记这个嵌套层级，直接传了个字典对象，导致飞书报错。

卡片发出去之后，用户在群里就能看到完整的会议信息，点按钮直接入会，不需要再去找会议号复制链接了。人在收到信息时的注意力是有限的，一张排版清晰的卡片，比一段纯文本的会议信息要好懂得多。

4.3 会议结束回调自动把纪要写进飞书云文档

会议结束后，腾讯会议会触发meeting.ended事件到我们配置的回调地址。我在回调处理函数里做了这么几件事：

第一步，解析事件类型。因为同一个回调地址可能收到创建会议、结束会议、录制完成等多种事件，所以要先判断event_type。

第二步，如果事件类型是会议结束，用事件里的meeting_id去调用腾讯会议的“获取会议详情”接口和“获取录制文件”接口。会议详情接口返回参会人列表、开始结束时间；录制文件接口返回录制地址、录制文件大小等。

第三步，把这些信息整理成结构化数据，调用飞书云文档API创建一份归档文档。飞书文档的创建接口是POST /open-apis/docx/v1/documents，创建成功后会返回一个document_id，然后可以用POST /open-apis/docx/v1/documents/{document_id}/blocks/{block_id}/children往文档里追加标题和段落块。

实际写文档时，我推荐先创建一个空文档，再分段写入。写入内容的顺序是：

1. 一级标题：会议主题。
2. 信息段落：会议时间、主持人、会议号。
3. 列表：参会人。
4. 链接段落：录制回放地址。

这一套流程跑通之后，真正的收益才体现出来：以前会议结束=信息丢失的开始，现在会议结束，归档文档自动出现在飞书里，链接自动发到群里，谁想看回放、谁要补纪要，都有据可查。

4.4 关于“飞书机器人发送表格”的落地姿势

网上经常有人搜“飞书机器人发送表格”，这个需求在对接场景里其实是个高频点。比如你可能希望会议结束后，把一张参会人名单表格推送到群里。这里我给出几种实测有效的方案，按推荐程度排序。

第一种是写云文档，再把链接推到群里。这也是我最推荐的方式。先用飞书电子表格API或者多维表格API把结构化数据写入，然后调用飞书消息接口，发送一个包含文档链接的卡片消息。好处是数据可筛选、可协作、可回看，不用每次重新生成。

第二种是渲染成图片再发。适合那种一次性查看、不需要二次编辑的场景。你可以用服务端工具把HTML表格渲染成PNG或者JPEG，然后调用飞书图片消息接口发送。稳定性和兼容性都不错，但生成过程多了一道渲染步骤。

第三种是纯文本等宽排版。最省事，但体验一般。飞书消息里用空格对齐表格列，一旦中英文混排，列就全歪了，只适合临时的调试场景，不建议作为正式方案。

这里要注意，飞书消息卡片本身对表格的原生支持有限，不同版本的客户端渲染效果差异也大。与其在卡片里硬塞表格，不如用“链接到云端表格”的思路，体验和可维护性都好得多。我后来把会议台账直接放到了多维表格里，机器人建会之后自动新增一条记录，会议编号、时间、入会链接都是独立字段，后续做统计分析非常方便。

5. 常见问题与排查技巧实录

5.1 鉴权失败：HTTP 200但业务code非0

对接这种开放平台，最迷惑人的一种情况是：HTTP状态码是200，请求也发出去了，但返回的JSON里业务code是一个非0的错误码。很多人习惯先看HTTP状态，一看200就以为成功了，结果解析数据时发现是空的。

飞书的返回结构一般是{"code": 0, "msg": "success", "data": {...}}，code为0才代表成功。腾讯会议的结构也类似，只不过字段名可能不同，但思路一致：先校验业务码，再取数据。排查时，把完整响应体打印出来看，根据错误码去查对应文档，常见的几种原因是：

• Token过期或无效：检查获取Token的时间，看是否超过了有效期。
• 权限点没生效：重新发布应用版本，等几分钟再试。
• 参数格式错误：比如时间戳用了毫秒，而API要求的是秒。
• 签名错误：检查签名串拼接顺序和密钥是否匹配。

我还在服务里做了一个统一的响应日志中间件，每次调用飞书或腾讯会议API，都会把URL、请求体、响应体完整记录到本地日志文件。排查问题的时候，这条日志能节省大量时间。

5.2 回调验证失败或收不到回调

腾讯会议回调验证失败，我遇到的情况有几种：

一是回调地址响应太慢。腾讯会议的验证请求有超时限制，建议回调服务先返回一个固定success，再异步处理业务。配置回调地址的时候，可以先在本地起一个最简单的Flask服务，只返回固定JSON，确认验证通过后再逐步加业务逻辑。

二是加密配置问题。如果开启了AES加密，但解密逻辑有问题，腾讯会议的验证请求会一直失败。排查方法很简单：先临时关闭加密，看验证是否通过，如果通过，说明加密环节出了问题。

三是公网地址没有配置证书。腾讯会议的回调要求是HTTPS，如果用IP地址或者没证书的域名，大概率验证不通过。这种情况可以先用内网穿透工具把本地服务暴露出去做验证，但正式环境还是建议上正规域名和证书。

飞书Webhook回调也有一套验证机制，首次配置的时候飞书会往你的地址发一个包含challenge的验证请求，你要原样把challenge字段返回，配置才能保存成功。如果用的是长连接模式，这个验证步骤就省掉了。

5.3 权限不足、找不到文档、不能访问对应空间

对接飞书云文档这类API时，报错最常见的是“permission denied”或者“document not found”。

遇到这个错误，第一步检查应用是否申请了对应权限点，比如docx:document和drive:drive；第二步检查应用版本是否已经发布并且被审核通过；第三步检查你用的Token是应用身份还是用户身份——调用云文档相关接口时，如果文档在用户的私人空间或者分享范围受限，就必须用user_access_token。

腾讯会议侧也有类似的权限问题。比如创建会议成功后，想查录制文件，但返回“没有权限”，很可能是你的应用没有申请录制文件相关的接口权限。如果确定权限没问题，再看调用者对应的用户ID是否真的参加了会议，腾讯会议的权限模型里，应用不能越权获取其他用户创建的会议。

5.4 腾讯会议摄像头、麦克风、录制设置问题

有同事问过“腾讯会议不能使用电脑自带摄像头吗”这个问题。先说结论：这大概率不是API的问题，而是客户端本机的权限设置。

用腾讯会议API创建会议时，API可以在settings里控制一些行为，比如mute_enable_join控制在入会时静音，allow_unmute_self控制成员能否自己解除静音，但API没法强制打开某个参会者的摄像头。参会者入会之后摄像头能否使用，取决于他自己的设备权限、浏览器权限、腾讯会议客户端的设置。

如果遇到无法使用自带摄像头的情况，排查顺序是：检查操作系统是否给了腾讯会议摄像头权限，Windows看“隐私设置”里的相机访问，macOS看“系统设置”里的隐私与安全性；再检查电脑上是否有多个摄像头设备，腾讯会议当前选中的是不是那一个；最后看会议设置里是否被主持人设为了“关闭摄像头”。API层面能做的，是尽量在创建会议时把设置项配好，减少与会者进入后的操作成本。

5.5 请求限流与生产环境稳定性

上线之后还要面对一个现实问题：开放平台都有接口限流。飞书和腾讯会议不会在文档里把每一条QPS写得面面俱到，但你如果一次性大量调用，一定会触发限流。

飞书的常见限流策略是应用维度和用户维度。我处理的方法是把tenant_access_token做缓存，避免每个请求都去获取一次Token，同时在调用写操作时做小批量的并发控制，比如发消息接口一次只发一条，不要用多线程并发刷。

腾讯会议的限流触发后一般会返回特定的错误码或HTTP 429。我的方案是做一个简单的重试机制：遇到限流错误，退避1秒、2秒、4秒依次重试，最多重试3次。如果多次重试还是失败，就把任务放到队列里缓存，等服务空闲了再补执行。

另外，生产环境的稳定性不光靠重试，还要靠监控。我给整个服务加了一个心跳接口，用定时任务每5分钟调用一次，如果连续几次没有心跳就告警。告警渠道直接用了飞书机器人，发到运维群里。这样对接服务即使挂了，也能第一时间被发现，不会出现会议都建好了、卡片迟迟没弹出的诡异情况。

回头总结一下这次实践，最想分享的一条经验是：这种跨平台对接项目，架构上没有难度，难点全在细节。Token的有效期、鉴权签名的拼接顺序、时间戳的单位、回调验签的格式，任何一个地方没对上，排查起来都可能耗费大半天。所以动手前先把两边权限模型和Token模型理清楚，再决定功能的实现顺序。先跑通一条最简单的链路，比如“飞书发消息→创建腾讯会议→回传卡片”，然后再逐步加会议归档、主动通知这些复杂功能。后面我们还计划把会议录制转写后的文本接给大模型做纪要摘要，再把摘要自动写回飞书文档，等跑通了再来分享。