随着大模型的普及，企业对内部数据安全和私有化问答的需求急剧上升。这个项目是我利用业余时间独立完成的一套 RAG (Retrieval-Augmented Generation) 架构的知识库 SaaS。

核心技术难点突破：

• 文档解析与切块 (Chunking)： 后端采用 Go 并发处理 PDF/Word 文档，运用滑动窗口策略进行文本切块，保证了上下文语义的连贯性。
• 向量检索： 弃用了早期的 PGVector，改用专业的 Milvus 向量数据库，在百万级 Chunk 数据下，检索耗时稳定在 50ms 以内。
• 前端状态管理： 借助于 AI 工具，快速攻克了 Vue3 复杂的打字机效果（SSE 流式输出）和长对话状态管理。

"这个项目让我彻底打通了从后端 API 开发到前端交互、再到大模型调用的完整闭环，证明了现代全栈开发的极大可行性。"

在大厂带队期间，我主导重构了公司的秒杀核心链路。该系统在双十一期间，成功顶住了 QPS 超过 50,000 的极高并发瞬时流量。

架构演进与避坑指南：

秒杀系统本质上是处理“读多写少”且极度不均衡的数据。我们的核心策略是：层层拦截，尽量把请求挡在数据库之上。

• 动静分离与 CDN 预热： 前端页面静态化，所有的抢购按钮在活动前由分布式配置中心统一控制点亮。
• Redis 预扣库存： 杜绝任何请求直接打到 MySQL。利用 Lua 脚本保证 Redis 扣减库存的原子性，彻底解决超卖问题。
• RocketMQ 异步削峰： Redis 扣减成功后，将订单信息丢入 MQ，下游订单服务根据自身处理能力慢慢消费入库。即使下游宕机，消息也不丢失。

做了10年后端，一直对前端写 CSS 和处理复杂的组件生命周期感到头疼。但最近，我仅用了一周业余时间，就独立上线了一款包含完整微信支付闭环的电商小程序。

我的工作流闭环

现在的开发不再是从零手敲代码，而是变成了“架构设计 + Prompt 引导 + 代码审查”：

• 后端： 依然用我最拿手的 Go (或 Java) 提供 Restful API，这点轻车熟路。
• 前端 UI： 扔一张参考截图给 Claude 3.5 Sonnet，直接让它生成一套基于 Tailwind CSS / Uni-app 的干净代码。
• 业务逻辑联调： 在 Cursor 中，选中后端 API 的 JSON 响应结构，通过 `@` 符号引入，让 AI 直接生成前端的请求逻辑和数据绑定。

后端思维的降维打击

其实只要解决了前端“画界面”的麻烦，后端程序员做全栈有着天然的优势。因为我们极度熟悉：数据库怎么设计、接口怎么防刷、分布式锁怎么加、支付回调怎么处理防重复。 这些才是真正决定一个系统能不能在生产环境跑稳的核心！

回首这十年的后端开发生涯，从最初单纯的增删改查（CRUD Boy），到后来面对庞大复杂的微服务架构，我对“架构设计”这四个字有了更底层的理解。

1. 架构是妥协的艺术

年轻时总喜欢引入最新的技术栈，什么火用什么。但真正的架构师明白，任何技术引入都有维护成本。不要为了微服务而微服务。 如果一个业务只有 3 个人维护，单体应用（Monolith）配合良好的模块化分层，远比拆分成 10 个微服务要高效得多。

2. 永远假设系统会挂

写业务代码和写架构代码最大的区别在于：前者假设一切正常，后者假设一切都会出问题。在微服务间调用时，必须把 超时控制、重试机制（注意幂等性）、熔断降级（Sentinel / Hystrix） 刻在骨子里。凌晨爬起来排查雪崩效应的痛，经历过一次就够了。

3. 数据的最终一致性

在分布式系统里，强一致性（如 2PC、3PC）往往意味着极差的性能。大部分业务场景下，采用 基于本地消息表 + 定时任务补偿 的最终一致性方案（Saga / 柔性事务），才是兼顾性能与业务正确的现实选择。