自研二进制协议要扛住"省、可切包、可分类、可加密、可演进"五条约束，这些原则听起来抽象，但落到一个真实跑在生产环境的 IM 服务端里，每一条都能在代码里指认到具体的类和字段。这篇文章以飞享IM（FshareIM）服务端 chat-server-pro 为例，从源码层面拆解这套自研协议是怎么把上述原则一条条实现出来的：10 字节包头怎么切包、Signal/SubSignal 两级命令字怎么分发、心跳和 ACK 怎么关联、AES 加密放在协议的哪个环节、版本位怎么预留，以及 TCP 二进制和 WebSocket JSON 这两条通道是怎么在同一个接入层里协同工作的。
飞享 IM 桌面端（electron-vue-chat-pro）收到一条反馈：切到含超长 Markdown 表格（系统通知日报）的会话时，界面会冻结小半秒，即便每会话消息数已经限制在 50 条以内。这篇文章记录的不是"我们做了个虚拟列表"，而是从这句模糊反馈到一个可放心合并的实现之间，中间每一步该做、且没有跳过的判断——用 Claude Code 全程执行，人负责拍板方向和最终验收。
在 ios-chat-pro 的 Vibe Coding 复盘之后，过去一周（7 月 5 日 – 7 月 12 日）我继续用 Claude Code 迭代这个 iOS IM 客户端，交替使用了两套 skill：superpowers（brainstorming → writing-plans → subagent-driven-development 的全流程套件）和 grill-me（开工前对设计方案进行"逼问式"访谈的单点 skill）。
飞享IM(FshareIM) 不是一份 PPT 里的 IM 系统方案，是真的在 Web、PC、iOS、Android 四端跑起来、每天有人在用的产品。这篇文章不讲代码，只用真实截图带你把这套系统从头看一遍：消息怎么同步、群怎么管、AI 机器人怎么在 IM 里推日报、音视频通话跨端能不能打通，以及——如果你想把它装到自己服务器上，需要什么。
这是一篇关于「人不看代码、AI 全程执行」的真实工程记录。ios-chat-pro 是飞享 IM 的 iOS 原生客户端，用 Swift + UIKit 实现，对接自研 TCP 协议和 protobuf 二进制消息，功能覆盖单聊、群聊、音视频通话、好友管理、群组管理、消息撤回。
这不是 changelog，这是一次「让你忍不住想打开试试」的功能盘点。v1.1.x 系列集中火力，专门干那些「表面没坏但其实很难受」的体验问题——流式回复占位符乱跑、时间显示不说人话、群视频通话有 bug、消息无法转发……全都修了，还顺手加了不少新东西。
分库分表不是一个简单的配置问题——它关系到分片键选择、扩容数学性质、跨分片查询策略，以及在不停服前提下如何安全迁移数据。本文以飞享IM（FshareIM）为案例，从现有手动分表方案的瓶颈出发，完整呈现三种技术路线对比、基于 ShardingSphere-JDBC 的新建分库方案、按 2 的幂扩容的数学推导，以及 Canal + 双写的零停机迁移时序，供 IM 系统架构师和 DBA 参考。
架构设计不只是画几张图——它是对整个系统的系统性思考：从业务需求到质量约束，从模块拆分到接口契约，从数据分表到故障容灾，再到 AI 融合与技术演进路线。本文以飞享IM（FshareIM）为参考，完整呈现一位架构师在一个生产级 IM 系统上应当完成的全部设计工作，涵盖六大职责分解、五阶段设计步骤，以及覆盖接入层、业务层、数据层、AI 架构、安全架构和部署架构的完整设计文档，附带技术决策记录（ADR）和架构评审检查单。
飞享IM（FshareIM）是一款支持私有部署的即时通讯系统，服务端采用 Java 实现，核心由 push-connector（接入层） 和 push-group（业务层） 两个服务组成。本文从实际运行角度梳理系统的13个核心技术模块，逐一说明当前方案的设计思路、存在的隐患，以及对应的改进建议，帮助开发者快速理解系统全貌。
基于飞享IM开源即时通讯系统，结合 LangGraph + Claude 构建的智能客服方案。用户在 IM 客户端与 AI 机器人对话，回答由 RAG 知识库驱动，流式逐字输出，体验接近原生对话。
