在 AI 中转站或模型网关中，我们通常会同时接入多个上游渠道，并通过优先级、权重、分组、模型映射等策略做调度。但在开启 NewAPI 的“渠道亲和性”之后，你可能会遇到一个看似反直觉的问题：
某个渠道已经失败，甚至已经被关闭了，但请求仍然不断命中旧渠道；新启用的高优先级、高权重渠道没有马上生效。
这并不一定是调度系统失效，而是“渠道亲和性”本身的设计结果：它会优先复用上一次成功的渠道，从而提升同一会话、同一缓存键、同一请求来源的稳定性。本文会解释这个机制的工作方式，并给出一套脱敏后的推荐配置，帮助你在稳定性和故障切换之间取得平衡。
某些项目在 macOS 上通过 IDE 打开时，会不断弹出类似下面的系统授权窗口：
git-credential-osxkeychain wants to use your confidential information stored in "gitlab.example.internal" in your keychain.
这类弹窗通常不是 GitLab 服务端异常，而是本机 Git 在访问 HTTPS remote 时，调用 macOS Keychain 凭据助手读取用户名、密码或 token。
在服务器场景中，有些虚拟机只用于单一服务、实验环境、GPU/AI 计算节点或内网运维节点，并不需要普通桌面用户目录，也不希望系统自动创建 /home 等额外分区。
Ubuntu Server 24.x 的安装器基于 Subiquity，默认安装流程会要求创建一个普通用户，并且默认磁盘布局可能会使用 LVM。这对很多通用场景是合理的，但如果目标是一个简洁的服务器系统，常见需求会变成：
root 用户；/home 分区；/；本文记录一套适用于 Ubuntu Server 24.x live-server 系列镜像 的完整安装流程，例如：
ubuntu-24.04-live-server-amd64.isoubuntu-24.04.1-live-server-amd64.isoubuntu-24.04.2-live-server-amd64.isoubuntu-24.04.3-live-server-amd64.isoubuntu-24.04.4-live-server-amd64.iso本文以 VMware ESXi 虚拟机为例，但安装器内的步骤同样适用于大多数虚拟化平台。
在 macOS 系统中使用 Git 时，经常会遇到一个令人困扰的弹窗：
"git-credential-osxkeychain" 想要访问你的钥匙串中的密钥 "gitlab.xxx.cloud"
更糟糕的是，当你打开"钥匙串访问"应用尝试删除这个凭证时，却发现：
这个问题的根本原因是 Git 凭证存储在 macOS 钥匙串中，但权限配置出现了异常，导致 git-credential-osxkeychain 工具无法正常访问凭证。
在实现静态 IP 多网卡策略路由时，遇到了一个令人困惑的问题：使用 ping -I 192.168.20.10（指定源 IP）可以正常访问外网，但使用 ping -I eno1（指定网卡接口）却完全无法连通。这个问题看似简单，实则涉及 Linux 内核路由查找机制、策略路由、反向路径过滤等多个底层技术细节。