从产假第一行代码到8000万用户的数字遗产：一个知识库20年的技术架构复盘
本文复盘360doc技术架构的演变历程，分析其从个人项目到知识管理第一股的技术密码，以及AI时代传统知识平台的技术困境。
2005-2010：单体架构支撑的草根时代
2005年，蔡智在产假期间用LAMP架构（Linux+Apache+MySQL+PHP）构建了360doc。这个选择务实而高效：开源免费、部署简单、技术门槛低。MySQL承担文章存储，文件系统管理附件，PHP处理前端逻辑。这套架构能支撑到2010年达到百万用户级别，说明早期技术选型是成功的。
关键决策：采用URL唯一化策略，每篇文章生成固定链接，便于搜索引擎收录。这为后来的SEO流量奠定了基础。
2010-2015：垂直扩展的性能瓶颈
用户量突破千万后，MySQL单库成为瓶颈。团队采用读写分离方案：主库写入，从库读取。同时引入Memcached做缓存层热点文章。这是典型的ScalingUp策略，用硬件换性能。
但问题随之而来：附件存储膨胀到数十TB。团队最终采用分布式文件系统方案，将图片、文档分流到独立存储节点。这个阶段的技术决策奠定了平台稳定运营的基础。
2015-2020：新三板上市后的架构重构
上市后面临合规压力。核心改动包括：用户密码迁移到bcrypt加密体系，日志脱敏处理，GDPR合规改造。技术债务清理需要大量人力，而小团队只有不到10人。
更致命的是，移动端适配滞后。当抖音、知乎占领用户手机屏幕时，360doc的移动端体验仍停留在响应式网页阶段，用户时长持续下滑。
AI浪潮下的技术困境
大语言模型能直接理解用户意图，精准回答问题。传统知识库的分层导航（分类→标签→文章）被语义搜索取代。用户不再需要收藏文章，AI会记住一切。
小团队无法负担大模型API成本，也无法快速迭代AI功能。技术上，平台架构是为关键词检索设计的，语义向量检索需要重建底层索引。
数据安全的最后防线
蔡智拒绝出售用户数据的决定，在技术层面意味着放弃了最后的变现通道。8000万用户的行为数据、收藏偏好、创作内容，若用于AI训练，价值不可估量。但她选择了关闭而非出卖。
技术团队在关站前的最后工作：数据导出接口优化、批量打包工具开发、用户通知系统启动。这些工作体现了职业素养——即使终点已定，也要站好最后一班岗。
对于技术从业者的启示：架构要有前瞻性，但不能过度设计；数据安全是底线，不是选项；技术只是工具，使命才是方向。
