技术

背景 用户点击后立即看到结果，体验很好；但失败回滚若恢复整份旧快照，可能覆盖期间已经成功的另一次修改。 核心判断 给操作分配版本或请求序号，响应只能提交到匹配的状态。 按业务项记录逆操作，避免整页数据回滚。 金额、库存等强约束操作由服务端结果裁决，界面明确 pending 状态。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 // DTO 列表只有原始字段；本例将更新串行化，防止旧回滚覆盖新操作。 async function update(action: Action) { if (pending.value) return; const before = items.value.map(item => ({ ...item })); pending.value = true; items.value = applyLocal(items.value, action); try { items.value = await api.update(action); } catch (error) { items.value = before; showError(error); } finally { pending.value = false; } } 边界与误区 structuredClone 不适用于所有 Vue 响应式对象；快照应从可克隆的原始 DTO 构造。乐观更新不等于后端幂等，也不能解决并发写冲突。 验证方式 示例将单次操作期间的后续操作串行化。用两次修改乱序成功、失败和超时验证回滚，不让一次旧失败清掉新结果。 小结 保存可回滚版本并给变更分配序号，失败时只撤销仍属于当前操作的部分。

背景 手写移动构造时，转移指针只做了一半。被移动对象后续仍会析构，目标对象也可能参与容器重分配。 核心判断 移动后源对象保持可析构、可赋值的不变量。 移动赋值先释放目标资源，并处理自移动策略。 只有所有操作确实不会抛异常时才承诺 noexcept。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 Buffer(Buffer&& other) noexcept : data_(std::exchange(other.data_, nullptr)), size_(std::exchange(other.size_, 0)) {} 边界与误区 示例是 Buffer 类内部的构造函数片段。能用 unique_ptr 或标准容器表达所有权时，优先遵循 Rule of Zero，减少手写特殊成员函数。 验证方式 覆盖空对象、非空对象、容器扩容、移动赋值和源对象析构，配合 AddressSanitizer 检查双重释放与泄漏。 小结 先定义资源不变量，再实现移动构造和赋值，保证 moved-from 对象可析构、可赋值。

背景 静态泛型可以保留具体类型，trait object 可以把实现选择推迟到运行时。选哪一种，应先看模块边界是否真的需要动态替换。 核心判断 同构热点内部优先清晰的泛型接口，异构集合或插件边界考虑 dyn Trait。 跨线程接口按实际需要约束 Send 与 Sync。 控制 trait 的职责与方法签名，让公共边界可测试、可演进。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 trait Storage: Send + Sync { fn get(&self, key: &str) -> Result<Vec<u8>, Error>; } fn read(store: &dyn Storage, key: &str) -> Result<Vec<u8>, Error> { store.get(key) } 边界与误区 并非所有 trait 都能成为 trait object；带某些泛型方法或返回 Self 的接口需要重新设计。示例只展示同步边界，Error 属于业务定义。 验证方式 实现内存与远程两种 Storage，验证调用方无需改动；在真实负载下测分派成本，不凭动态调用次数推断整体性能。 小结 内部高频路径优先静态分发，插件和依赖注入边界再使用 trait object。

背景 上游请求已经超时，下游却继续查询和计算，会把一次失败变成额外资源消耗。context 的作用是传播工作预算，而不是传递任意配置。 核心判断 从入口传递同一条取消链，连接请求与数据库调用都使用带 context 的 API。 派生超时必须调用 cancel 释放资源。 后台独立任务重新定义生命周期，不偷偷继承即将结束的请求 context。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 func Fetch(ctx context.Context, url string) ([]byte, error) { req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil) if err != nil { return nil, err } resp, err := http.DefaultClient.Do(req) if err != nil { return nil, err } defer resp.Body.Close() if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("unexpected HTTP status: %s", resp.Status) } const maxBody = 1 << 20 body, err := io.ReadAll(io.LimitReader(resp.Body, maxBody+1)) if err != nil { return nil, err } if len(body) > maxBody { return nil, fmt.Errorf("response exceeds body limit") } return body, nil } 边界与误区 创建 HTTP 请求也可能失败，不能忽略错误。取消是否能及时生效取决于被调用的操作；CPU 循环需要自行检查，返回后也要关闭响应体。 验证方式 让服务端延迟返回，在客户端取消后检查耗时、错误与 goroutine 数。对大响应设置读取预算，避免取消之外的无界内存消耗。 小结 所有阻塞操作都绑定上游 context，重试循环和 channel 等待必须响应 Done。

背景 每个页面各写一遍 fetch，最终会产生不同的超时、错误和 JSON 解析行为。统一客户端是把网络不确定性收敛到一个边界。 核心判断 统一取消、超时、HTTP 状态与响应解析。 领域接口接受运行时解码器，不靠 request 断言服务端数据。 区分网络失败、HTTP 拒绝和响应契约错误，供界面选择恢复策略。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 async function request<T>( input: RequestInfo, decode: (value: unknown) => T, ): Promise<T> { const response = await fetch(input, { signal: AbortSignal.timeout(5000), }); if (!response.ok) throw new ApiError(response.status); const value: unknown = await response.json(); return decode(value); } 边界与误区 AbortSignal.timeout 需要目标运行环境支持。204 无响应体、非 JSON 错误页和调用方取消也要处理；示例适用于约定 JSON 正文的接口。 验证方式 用 mock server 覆盖慢响应、401、500、畸形 JSON 和错误字段。检查同一错误类型在不同页面的提示与重试策略保持一致。 小结 客户端统一处理超时、取消、解析和错误，领域层只暴露稳定的方法和错误分类。

背景 被阻塞的 SQL 不一定是罪魁祸首，真正的阻塞者可能已经 idle in transaction。排障要先还原阻塞链和事务年龄。 核心判断 用 pg_blocking_pids 获取阻塞者，再关联 pg_stat_activity。 同时观察 wait_event、xact_start 和应用名，判断锁等待来源。 先与业务方确认事务副作用，再决定取消语句或终止会话。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 SELECT blocked.pid AS blocked_pid, blocker.pid AS blocking_pid, now() - blocker.xact_start AS blocking_xact_age, blocked.wait_event_type, blocked.wait_event, blocked.query AS blocked_query, blocker.query AS blocking_query FROM pg_stat_activity AS blocked CROSS JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS p(pid) JOIN pg_stat_activity AS blocker ON blocker.pid = p.pid ORDER BY blocking_xact_age DESC NULLS LAST; 边界与误区 仅按 locktype 连接 pg_locks 会错误关联不同锁对象。示例使用官方阻塞关系函数；高频查询也有开销，诊断权限与采样频率应受控。 验证方式 建立一个长事务持锁，再让第二个连接等待，核对阻塞 PID 与 SQL。确认取消当前语句和结束整个会话的风险不同，不自动执行终止命令。 小结 监控阻塞者、被阻塞者、事务年龄和 SQL，区分长事务、DDL 与业务冲突。

背景 同一次故障分散在网关、服务和消息消费者里，靠时间搜索日志很容易混入其他请求。需要统一的关联字段与传播协议。 核心判断 从当前有效 span 提取 trace_id 和 span_id，再构造结构化日志。 请求 ID 保留入口语义，版本与服务名帮助定位发布差异。 跨消息边界显式注入和提取追踪上下文。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 logger := slog.With("trace_id", traceID, "span_id", spanID); logger.Error("payment failed", "order_id", orderID) 边界与误区 示例中的 ID 来自业务上下文，不是任意字符串。未采样请求也可以有 trace ID，但追踪后端不一定留存该 trace，日志必须仍能独立排障。 验证方式 发送一个跨服务并经过队列的请求，检查各段日志的关联一致性；再覆盖无父级上下文、未采样请求与消费者重试。 小结 日志统一输出 trace_id、span_id、request_id 和版本，异步消息显式传递上下文。

背景 CPU 利用率不高但请求很慢，可能是线程在等待 I/O，也可能是锁或远程依赖。iowait 只是入口，不是瓶颈的最终解释。 核心判断 把设备延迟、队列、吞吐与进程读写速率对齐到同一时间段。 结合 PSI 和 D 状态线程判断是否存在实际阻塞。 区分同步写、刷盘、随机读和后台维护流量。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 iostat -xz 1 5; pidstat -d -w 1 5; vmstat 1 5; cat /proc/pressure/io 边界与误区 sysstat 工具需要预先安装；PSI 支持取决于内核配置。单看 util 或 iowait 无法解释多队列设备的饱和程度。 验证方式 在已知顺序读和同步写场景下采样建立对照，再关联业务 p99。只有确认瓶颈来自存储路径，才讨论更换磁盘或增加并发。 小结 同时观察 PSI、磁盘延迟、队列深度、进程状态和请求耗时再定位瓶颈。

背景 把密码放进 Secret 比写进镜像更容易管理，但 base64 编码本身没有保密能力。真正的安全边界是访问控制与生命周期。 核心判断 限制读取 Secret 的 RBAC 与可访问的命名空间。 按需注入指定键，避免 envFrom 暴露无关凭据。 设计轮换流程，并确认应用如何重新加载新值。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 envFrom: - secretRef: { name: api-credentials } # 生产环境应结合外部密钥系统和最小 RBAC 边界与误区 环境变量不会随 Secret 轮换自动更新。卷投射的刷新也不是实时保证，subPath 挂载行为要单独确认；备份与 etcd 静态加密同样需要考虑。 验证方式 轮换一次测试密钥，检查应用何时生效、旧密钥何时撤销以及日志是否泄露值。权限演练要验证无关 ServiceAccount 不能读取它。 小结 Secret 的 base64 不是加密，权限、轮换、挂载方式和审计才是完整控制。

背景 镜像标签只能说明一个名字，不能说明产物来自哪个提交、在哪个环境构建。供应链证明应绑定不可变的镜像摘要。 核心判断 SBOM 描述依赖，provenance 描述构建来源，签名证明被信任的身份。 部署使用 digest，并在准入或发布流程中验证身份与来源。 将失败验证设为阻断，而不是只把证明存到制品库。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 steps: - uses: docker/build-push-action@v6 with: { push: true, provenance: mode=max, sbom: true } 边界与误区 示例只产生构建证明，不会自动生成独立可信签名。Action 的 major 标签也不是不可变引用，生产流水线应锁定审查过的 commit。 验证方式 修改源码或构建参数后检查 digest 与证明变化；再模拟错误签名身份和缺失证明，确认部署会被拒绝。避免构建证明泄露敏感构建参数。 小结 用 SBOM、provenance 和签名把镜像摘要绑定到源码提交和构建过程。