范文多多

切片是 Go 里最容易被误用的数据结构之一。很多人知道「append 可能触发扩容」，但真正写业务代码时，仍然会踩进同一个坑：函数里对切片 append 之后，调用方的数据没变；或者两个切片共享底层数组，改一个另一个跟着变，排查半天才发现是别名（alias）问题。这篇文章不讲概念复述，而是给出可运行的判定手段：怎么用 unsafe 拿到底层数组指针来判断扩容

这道面试题的问法通常是：如果传给 sync.Once.Do 的函数在执行过程中 panic 了，那么之后再调用 Do，这个函数还会不会再执行一次？很多人第一反应是「会，因为没执行成功」，也有人觉得「不会，因为 Once 标记为已执行」。两种回答都只说对了一半，而且在不同 Go 版本上行为并不一样。要答准，必须回到 sync.Once 的源码：done 这个原

把 docker compose up -d 直接写进发布脚本，是很多团队踩过坑的做法。问题不在命令本身，而在于 Compose 文件的解析发生在容器真正启动之前：当 .env 缺变量、YAML 缩进错位、端口写成字符串、挂载路径引用了未定义变量时，报错往往夹杂在镜像拉取和容器创建日志里，排查成本高，而且失败可能发生在替换了部分容器之后，留下半新半旧的状态。

面试里问 Pipeline，多数人能答出「一次 RTT 发多条命令、减少网络往返」。再往下追问一句：一批命令通过 Pipeline 发出去，第 3 条因为类型错误失败了，第 4、5 条到底执不执行？已执行的那几条会不会回滚？很多候选人就答得含糊了。这个问题的价值在于，它同时考察三件事：Pipeline 与事务的区别、Redis 单线程执行模型、以及客户端侧的

多业务共用一套 Redis 时，最容易出的事故不是缓存击穿，而是键名冲突导致的静默覆盖：订单服务写 order:1001，营销服务也写 order:1001，两边都不报错，只是数据隔一段时间就"莫名其妙"变一次。排查时日志干净、监控无异常，因为从 Redis 的视角看，这就是一次合法的 HSET。本文给出一套低成本方案：把命名空间的归属信息写进同一个 Has

业务里给对象挂"额外信息"是很常见的需求：ORM 的实体要记住自己是脏的、事件总线要记录监听器归属、序列化器要给对象打标记、DI 容器要保存单例的构造状态。最直接的做法是在对象上开一个 public $meta 属性，或者用 spl_object_id($obj) 当 key 塞进一个静态数组。前者侵入业务模型，后者在长生命周期进程（如 Swoole / R

做前端状态管理或 SDK 封装时，经常要写一层代理对象：它包住一份内部数据，外部只能通过 get('userName') 这类方法读取字段。麻烦在于，字符串键名没有任何类型信息——拼错一个字母、改字段名忘了同步、访问一个不存在的属性，TypeScript 全都放行，等到运行时才返回 undefined，排查链路直接拉到最长。本文解决的就是这件事：利用 K e

在异步 Rust 里同时等待多个数据源，最直接的写法是 tokio::select!。但它有一个不太显眼的语义：select! 只负责「谁先就绪就返回谁」，不负责「等多久就不等了」。当某个分支既不返回数据也不报错——比如一个长时间静默的 WebSocket、一个对端迟迟不发心跳的 TCP 连接、一个被上游限流卡住的 HTTP body——整个 select!

很多团队的文件同步仍停留在 rsync 或 scp -r 一把梭的阶段，一旦目标机器只开放了 SFTP 且没有 shell 权限，或者需要在同步前做业务侧的白名单、过滤、二次处理，命令行工具就不够用了。更麻烦的是全量覆盖：源端有几千个文件，每次同步都重传一遍，带宽和时间都被浪费。本文给出一个纯 Python 的方案——用 paramiko 建立 SFTP 会