跨平台发布：状态、幂等性与西里尔字母问题
将文章自动发布到社交网络，这项任务乍一看似乎很简单，但实际上却变成了一个复杂且充满故障点的管道。在本文中，我们将探讨状态、幂等性以及编码问题如何影响批量发布的可靠性，以及如何构建一个工作流程而避免意外。
管道架构：分阶段划分
关键思想是将流程划分为独立的阶段：来源 → 内容包 → 媒体解析 → 传输 → 验证 → 报告。这样可以定位错误并明确每个阶段的责任。
包、传输和质量控制
包负责材料，传输负责交付，质量控制负责执行证明。这种划分有助于避免混乱，当代理“自己做所有事情”时，无法确定错误究竟发生在哪里。
Telegram的问题：超时和重复
第一个事件：CLI返回了网关超时（10000毫秒后），尽管帖子已经发布。重新发送导致了重复。结论：不成功的传输响应不是重复执行具有副作用操作的理由。首先需要检查发布事实。
消息格式：Markdown与HTML
Markdown链接在视觉上与文本融为一体。解决方案——将消息格式固定为一组可验证的条件：简短预告、HTML锚文本、段落分隔。
浏览器作为后备方案：VK、OK等
浏览器脚本（noVNC）表现出不稳定性：VK的反机器人检查、图片加载问题、OK中预览卡片的丢失。浏览器仅保留作为应急路径，主要传输方式为延迟发布服务的API。
API响应：并非成功的保证
HTTP 201和scheduled并不能证明发布将正确进行。对于每个平台，都需要可验证的最终状态：帖子ID、状态。否则，启动不能视为成功。
图片：解析器和验证规则
问题：WebP并非所有地方都支持，Google Drive破坏预览，HEAD请求具有欺骗性。解决方案——独立的图片解析器，并附带规则：公开URL、合适的格式、大小在限制内、通过实际下载检查MIME类型。
西里尔字母和U+FFFD：损坏的字符
Google Doc中出现了Unicode替换字符（U+FFFD），表示数据丢失。自动修复这是不可能的。因此引入了字节检查（EF BF BD）和硬性门禁：如果检测到编码损坏，传输不会启动。
为Dzen和Spark重写：内容来源
来自API的JSON被证明是糟糕的来源：出现了CTA、横幅。解决方案——使用完整的公开HTML，随后清理不相关的块。检查结构、体积、无CTA。
限制责任范围：每次启动一篇文章
一次处理多篇文章会导致错误扩散。在技能中固定了限制：一次自动启动——只有一篇新的未发布文章。
最终报告：从状态渲染
报告应基于事实构建，而不是基于模型记忆。存储启动状态：文章URL、包状态、媒体、每个渠道、阻塞因素。这样可以避免虚假陈述。
停止因素：将错误转化为规则
每个错误都成为停止因素：固定的标题格式、发布事实检查、删除URL前检查卡片、MIME规则、字节检查、HTML清理、渠道状态检查。这使流程变得可靠。
工作程序
- 选择一篇新文章。
- 获取HTML并清理不相关的内容。
- 构建包：预告、两个重写版本。
- 检查结构、体积、链接。
- 运行编码质量控制。
- 解析并检查媒体。
- 生成Google Doc。
- 直接发布到Telegram。
- 通过LiveDune安排其他渠道。
- 检查每个平台的状态。
- 如果状态未证明，则以错误结束。
常见问题
如何避免超时时的重复？
在重新发送前检查发布事实。如果帖子已发布，不要重复操作。
为什么WebP不适用于所有平台？
一些社交网络不支持WebP或有大小限制。使用转换为PNG/JPEG并检查大小。
如何验证发布确实已安排？
使用API获取帖子ID和状态。只有确认状态存在才算成功。
结论
跨平台发布不仅仅是一个操作，而是一个具有多个故障点的系统。引入停止因素、状态检查和限制，将混乱转变为可控流程。从小处着手：划分管道，添加质量控制，并确保每个错误都成为规则。