设计哲学

为什么选择 Rust？为什么这样设计？架构决策的来龙去脉。

为什么是 Rust

站群系统是长生命周期的基础设施，运行时间以年为单位。Rust 的三个核心特性直接对应系统长期运行的核心需求：

• 内存安全 —— 编译器保证不存在空指针、悬垂指针、缓冲区溢出。传统语言中这类 bug 往往在生产环境运行数月后才暴露，排查成本极高
• 零成本抽象 —— 高级语法（迭代器、闭包、async/await）编译后与手写底层代码性能一致，不需要在可读性和性能之间妥协
• 无畏并发 —— 所有权系统在编译期杜绝数据竞争，异步代码不需要担心共享状态的同步问题

子站数据隔离，互不感知

子站是系统里的一等实体：各自独立的模板目录、独立的上传文件目录，数据库层面按站点严格隔离，一个子站的用户看不到、也访问不到其他子站的数据。子站之间要协作，走的是"内容推送、接收方独立审核"这种显式流程，不是共享数据库表意义上的"互通"。

编译期安全 > 运行时校验

rsSites 把安全检查尽可能前置到编译期：SQLx 在编译时校验 SQL 语法和字段类型、Axum 在编译时校验路由参数类型、serde 在编译时生成序列化代码。运行时不是没有防护（限流、认证、文件校验一个不少），但"这个字段名拼错了"这类问题在 cargo build 阶段就能发现，不需要等到上线后从日志里排查。

分层架构

routes 只做参数解析和序列化，services 承载所有业务逻辑。同一份 service 函数被 HTTP handler 和 CLI 子命令共享调用——批量脚本、定时任务、AI 自动化对接的都是同一套业务代码，不存在"Web 版一个逻辑、命令行版另一个逻辑"的问题。

不引入不必要的复杂度

一个站群系统的日常规模通常撑不满一台机器的零头。架构决策遵循"足够好即可"原则：不做微服务、不引入消息队列、不依赖对象存储。单进程 + PostgreSQL + Redis 三板斧解决所有问题——少一个组件，就少一处能出故障、少一处要运维的地方。等规模真正增长、瓶颈真正出现时，再针对实际问题做优化，不为想象中的未来买单。