背景 不是所有性能优化都要上自研内存池。很多时候，std::pmr 已经能解决不少问题。 一个实用场景 请求处理阶段会构建很多临时字符串和容器，生命周期一致，适合放在同一块内存资源里。 #include <memory_resource> #include <string> #include <vector> void handleRequest() { std::byte buffer[4096]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); std::pmr::vector<std::pmr::string> fields{&pool}; fields.emplace_back("user", &pool); fields.emplace_back("email", &pool); } 总结 pmr 的价值在于“低侵入地控制分配策略”。 在临时对象密集场景里，收益通常比预想更明显。 能用标准库解决的问题，优先别把复杂度推到自研。
背景 很多部署问题，其实在本地就埋下了： 本地依赖版本和线上不同 环境变量缺省值不一致 本地绕过了鉴权或网络策略 一个简单做法 用 Compose profile 区分场景，但保持核心依赖一致。 services: app: build: . env_file: .env depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7 总结 环境一致性不是“完全一样”，而是“关键契约一致”。 只要契约一致，很多线上问题能在开发期提前暴露。 部署质量往往从本地开发流程就开始决定了。
先澄清核心矛盾 无锁链表里，线程 A 可能刚把节点从链表摘下，线程 B 还在读取它。此时直接 drop 会造成悬垂引用。 两类主流方案 Epoch Based Reclamation（EBR） 线程进入临界区时 pin 当前 epoch。 删除节点先放入 retired 列表。 只有当所有线程都跨过该 epoch，节点才可释放。 Hazard Pointer（HP） 读取前先声明“我正在看这个指针”。 回收线程扫描所有 hazard slot。 未被保护的 retired 节点才能释放。 EBR 的工程特性 吞吐通常更高，读路径开销小。 线程暂停会拖慢全局回收进度。 更适合短临界区、线程活跃的服务。 HP 的工程特性 回收更精细，不容易被慢线程拖住。 读路径需要发布 hazard，CPU 开销更高。 更适合线程生命周期不可控的系统。 Rust 落地建议 // 伪代码：删除节点不立即释放，而是 retire fn remove(node: Shared<Node>, guard: &Guard) { if cas_unlink(node, guard) { guard.defer_destroy(node); // 交给回收器延迟释放 } } 使用经过验证的库（如 crossbeam）而不是手搓回收器。 把“最大 retired 数量”做成指标，防止隐性内存膨胀。 压测时加入 SIGSTOP 慢线程场景，验证回收鲁棒性。 小结 锁不一定是瓶颈，错误回收一定是灾难。无锁结构上线前，先证明回收策略在“慢线程、抖动、长尾”下仍可控。
背景 很多 Go 服务都会做 worker pool，但只做“固定 worker 数量”还不够。 真正决定稳定性的，是池子打满后怎么办。 基础模型 type Job func(context.Context) error type Pool struct { jobs chan Job } func NewPool(workerN, queueN int) *Pool { p := &Pool{jobs: make(chan Job, queueN)} for i := 0; i < workerN; i++ { go func() { for job := range p.jobs { _ = job(context.Background()) } }() } return p } 关键点：拒绝策略 func (p *Pool) TrySubmit(job Job) error { select { case p.jobs <- job: return nil default: return errors.New("worker pool saturated") } } 当队列已满时，快速失败通常比无限排队更可控。 总结 worker pool 的目标不是“永不拒绝”，而是让系统在高峰时有可预测行为。 配合监控和限流，才能构成完整保护链路。 可用系统的关键是边界清晰，而不是无限扛压。
问题画像 线上最危险的不是“改表”，而是“业务和改表耦合发布”：应用已读新字段，但 DDL 还没完成；或者 DDL 成功了，回滚却读不懂新结构。 迁移模型：Expand -> Migrate -> Contract Expand：只做向后兼容变更（加列、加索引、双写入口）。 Migrate：后台回填与数据校验，逐步把读流量切向新字段。 Contract：确认没有旧路径后，再删旧列/旧索引。 Go 侧发布顺序 // 第一步发布：双写 + 旧读优先 func SaveOrder(ctx context.Context, o Order) error { row := model.OrderRow{ ID: o.ID, // old_total 保持兼容 OldTotal: o.Total, // new_total 为新字段 NewTotal: decimalPtr(o.Total), } return repo.Upsert(ctx, row) } // 第二步发布：读新字段，失败回退旧字段 func LoadOrderTotal(r model.OrderRow) decimal.Decimal { if r.NewTotal != nil { return *r.NewTotal } return r.OldTotal } 回填策略 按主键区间分页，避免大事务长时间占锁。 每批记录校验 checksum，把异常写入死信表。 回填作业限速，和在线业务共享数据库 QPS 预算。 观测与止损 指标：回填进度、回填错误率、慢 SQL、锁等待时间。 开关：双写开关、读路径开关、回填暂停开关。 预案：任意阶段都能回到“旧读+旧写”。 常见坑 在 Expand 阶段做非兼容 DDL（例如直接改列类型）。 回填任务不幂等，重跑会污染数据。 只关注“DDL 成功”，忽略“业务一致性成功”。 小结 零停机迁移不是一条 SQL，而是一条发布流水线。把数据库变更当成可灰度、可观测、可回滚的工程流程，风险会从“不可控事故”变成“可管理演进”。
背景 Axum 用起来很顺手，但真实项目里经常出现一个隐性问题： 中间件越加越多 顺序靠经验调整 出故障时不知道是哪个层拦住了请求 推荐分层 从外到内通常建议： request id / tracing panic recover 全局限流 认证鉴权 业务路由 let app = Router::new() .route("/api/user", get(get_user)) .layer(TraceLayer::new_for_http()) .layer(RequestIdLayer::new()) .layer(TimeoutLayer::new(Duration::from_secs(2))); 总结 中间件不是“越多越安全”，而是“每层职责清晰、顺序可解释”。 发布前做一次链路压测，往往能提前发现大部分分层问题。 架构清晰的系统，异常路径也应该清晰。
背景 很多集群的问题，最后都落在资源配置上： requests 太高，调度不进去 requests 太低，服务被抢占导致抖动 limits 太严，CPU 被频繁 throttling 基本策略 先测业务基线，再填 requests CPU limits 结合业务特性决定是否设置 内存 limits 必须有，否则容易把节点拖垮 resources: requests: cpu: "300m" memory: "512Mi" limits: cpu: "1000m" memory: "1Gi" 观测指标 建议持续看： container_cpu_cfs_throttled_seconds_total container_memory_working_set_bytes Pod OOMKilled 次数 总结 资源参数不是一次性配置，而是持续调优过程。 用监控数据驱动参数调整，比凭经验拍数值更靠谱。 资源治理本质是容量治理，最终影响的是可用性和成本。
背景 后台系统里最难维护的页面之一，就是大表单： 字段多 联动多 校验规则多 草稿和提交逻辑分叉 如果状态设计不清晰，后期改一个字段就会牵动全局。 实用拆分 表单值与 UI 状态分离 同步校验与异步校验分离 页面状态按分区拆 composable const formValue = reactive({ name: '', email: '', company: '', }) const uiState = reactive({ submitting: false, dirty: false, activeTab: 'basic', }) 防止无效重渲染 大对象不要全量深监听 使用按字段 watch 拆分子组件隔离更新范围 watch( [() => formValue.email, () => formValue.company], () => { validateContactFields() } ) 总结 大表单的关键不是“怎么写更快”，而是“怎么改不炸”。 前期做好状态边界，后期迭代成本会低很多。 复杂页面最终拼的是可维护性，不是首版速度。
背景 高并发网络服务里，Reactor 和 Proactor 是两个绕不开的模型。 很多争论其实都在混淆一个问题： 你是在等“就绪事件” 还是在等“异步操作完成事件” 核心差异 Reactor 内核告诉你哪个 fd 就绪 业务线程自己 read/write Proactor 业务先发起异步 IO 内核完成后通知你结果 在 Linux 常规栈里，很多框架本质上还是 Reactor；在 io_uring 这类能力更强的接口下，Proactor 风格更容易落地。 简化示意 // Reactor 风格：事件到达后主动读 void onReadable(int fd) { char buf[4096]; ssize_t n = ::read(fd, buf, sizeof(buf)); if (n > 0) { handleRequest(buf, n); } } // Proactor 风格：提交后等待完成回调 void submitRead(Connection* c) { io_uring_prep_read(c->sqe, c->fd, c->buf, c->cap, 0); } void onReadComplete(Connection* c, int res) { if (res > 0) { handleRequest(c->buf, res); } } 选择建议 现有生态以 epoll 为主：优先 Reactor 追求极致吞吐且能接受复杂度：考虑 Proactor/io_uring 团队经验不足时，别为“更先进”盲目迁移 总结 模型没有绝对优劣，只有场景匹配。 ...
背景 CI 最容易浪费时间的阶段之一，就是镜像构建。 常见慢点： 每次都重新下载依赖 layer 顺序不合理导致缓存失效 多架构构建没有缓存复用 BuildKit 的关键能力 cache mount 并行构建 远程缓存导入导出 # syntax=docker/dockerfile:1.7 FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN --mount=type=cache,target=/go/pkg/mod go mod download COPY . . RUN --mount=type=cache,target=/root/.cache/go-build \ CGO_ENABLED=0 GOOS=linux go build -o app . GitHub Actions 示例 - uses: docker/setup-buildx-action@v3 - uses: docker/build-push-action@v6 with: context: . push: true tags: ghcr.io/org/app:latest cache-from: type=registry,ref=ghcr.io/org/app:buildcache cache-to: type=registry,ref=ghcr.io/org/app:buildcache,mode=max 总结 提速的核心不是换机器，而是设计好缓存路径。 构建系统越早做缓存治理，团队长期效率越高。 CI 慢不是宿命，很多时候只是缓存没被认真设计。