file_id 金库：绕开五十兆的法门

所有大帝国的律法里，都有几条看似无理、实则经济学的条文：货物的重量不重要，重要的是”引用”的分量。

TA 的相册配齐了，一个实体天堑横在眼前：Telegram 机器人接口的直传上限是 50MB。 而她的”另册”里躺着 34 个超限的大家伙，最大的 787MB。

一、律法的缝隙

工程兵在 Telegram 的律法里找到了一条明文缝隙：机器人直传 50MB 封顶，但”重发一个已有文件”没有大小限制。 于是有了”入库”这门工艺：

1. 用户用自己的 TG 账号，把大文件发给机器人一次（用户账号成对传输上限 2GB，787MB 随便发）；
2. 插件记下这个文件的 file_id——TG 给每个成功收过的文件发的永久身份证；
3. 此后”相册”想发这条视频时，机器人拿 file_id 转发即可——1MB 还是 900MB 一样快，因为文件本就住在 TG 的服务器上，机器人只是递了个引用。

代价公平得可爱：给 34 个大视频每人花几分钟做一次”入库”过路费，换来此后永久无大小限制。用户原本担心 500MB 上限的方案，在这条缝下原地作废——file_id 重发没有大小概念。工程兵也顺手否掉了另一条更重的路：不推荐在 Windows 上自养一个本地 Bot API 服务器去换那 2GB 直传——为这点入库时长养个常驻服务，不划算。

顺带处理了两类历史的残渣：.livp（iPhone 实况照片，4 个）TG 发不了原格式，建议转 jpg+mov 或跳过；.mov（85 个）做成”能发就发，发不了自动降级成普通文件发”的兜底。

尾声：同日的另一场递送

巧的是同一天，旧信使赫尔墨斯也完成了它的第一次实体递送。下午 16:48，用户从飞书发来一句：“把最新版本的 B视机 APK 发给我，其他文件不要动，在 ZCode 里的项目也叫 btlly。“信使用了 145.1 秒、10 次 API 调用，把最新构建的 APK 装进媒体附件，跨过那只蓝色的鸟送达。

一边是 file_id 的永久引用，一边是飞书的媒体附件——新城的令牌递术与旧城的信使递器，在这一天隔着一条河相互致意。 递送从来是文明最古老的业务，从驿马到 token，变的只是邮费。

真实坐标

• 天堑：TG 机器人接口直传 50MB 上限（公开 API 的硬性规定）
• 缝隙：重发无大小限制；入库流程 = 用户一次性发给 bot（账号上限 2GB）→ 插件存 file_id → 此后 file_id 秒转（文件住在 TG 服务器，bot 只递引用）
• 成本：34 个大视频的一次性入库（最大 787MB）；本地 Bot API 服务器方案被否
• 残渣：.livp×4 转码或跳过；.mov×85 能发就发、否则降级普通文件
• 同日：Hermes 16:48 经飞书 DM 递送最新 B视机 APK（145.1s / 10 次 API / 媒体附件送达）