Go / 实时通信 / 后端基础设施
Go 实时后端，把通信链路做成可替换底座
我做过 Go 后端和实时通信基础设施，把 WebRTC、IM、业务事件拆成清晰契约。服务可以独立部署，客户端不必被某一种通信方案锁住。
Go · gRPC · PostgreSQL · 实时链路
后端能力不是简历标签，是能不能撑住真实流量
Go 主要用在高并发 API、实时消息和基础设施胶水层。分层、原生 SQL、缓存和消息链路都要能解释清楚，出问题时也能追到具体边界。
我更看重契约和部署形态：服务可以单独上线，依赖可以隔离，客户端和业务层不被底层通信方案绑死。
- Go / Gin REST API
- gRPC publish 与 WebSocket 订阅链路
- PostgreSQL / Redis / 原生 SQL
- WebRTC / IM 插件化抽象
- 可独立部署的实时基础设施
定位
做产品，也能接住系统复杂度
我适合的不是单点页面或单个接口，而是需要把移动端、后端、AI、发布和运维一起接起来的工作。过去的底层和金融科技经验，让我在独立做产品时仍然先看边界、稳定性和长期维护。
公开作品
已上架应用
主要能力
把复杂工作拆成可交付的链路
iOS、React Native / Expo、Flutter 都做过；该回原生、处理启动链路或性能细节时不会停在业务层。
Go / Gin、PostgreSQL、Redis、gRPC、Docker 到 AWS EKS / Kubernetes，能从接口契约一路看到部署和回滚。
把 LLM、RAG、长期记忆、提示词和多 Agent 协作放进可验收的流程里，而不是只拼一个 Demo。
构建、发布、健康检查、告警、证书和域名问题都能一起排查；上线要有证据，失败要能定位。
复杂场景
独立做应用之外，也做过生产系统
这里重点呈现可公开的技术经验：实时通信、Go 后端、云原生迁移、CI/CD、运维巡检和 Agent 编排。
把 IM、WebRTC、业务事件和客户端订阅拆成清晰契约；后端服务可以独立部署，客户端不用被底层通信方案锁死。
Go · gRPC · WebSocket · PostgreSQL做过生产迁移到 AWS EKS 的方案，覆盖容器镜像、Helm、Ingress、密钥、数据库、缓存、维护窗口、回滚和健康检查。
AWS EKS · Kubernetes · Helm · CI/CD公开代码
开源项目
给 AI Agent 用的自托管记忆服务，负责检索、RAG 和多模态资料入库。
- 按容器隔离资料，也支持跨容器检索
- LanceDB 向量检索和 LightRAG 知识图谱一起用
- 支持 PDF、图片、表格等多模态资料入库
- 通过连接 token 接入 Claude、Gemini、Cursor 等工具
技术栈
更完整的全栈维度
经历路径
从一线工程到独立交付
设计与实现
一致性与辨识度
视觉、配色和组件系统通常自己收口。尽量用统一规则保持一致性，再给每个产品留出足够辨识度。
共享一套基础规则，再根据产品语境调整配色、图标和细节。
推进方式
我怎么把事情往前推
先做可用版本，再决定值不值得继续投入。
AI 用来提速，不替代判断；进流程前先把边界写清楚。
上线前把关键路径、数据来源和异常情况逐项核对。
根据反馈修订，而不是把首发版本当终点。