同一套命令，两个世界：我给 Claude Code 和自己做了套双轨终端

文章记录了作者为区分个人终端与 Claude Code 命令环境而重构配置的过程：Bash 会把 `.bashrc` 状态快照给智能体，因此用 `CLAUDECODE` 分流，个人加载增强别名，智能体清除系统别名；PowerShell 因以 `-NoProfile` 启动，无需同样分流。实践揭示多项隐蔽风险，包括误判别名的测试、PowerShell 命令优先级与 5.1 的 BOM 编码问题，以及覆盖 `diff` 破坏脚本语义。作者以 75 条断言从文件、加载结果和真实行为三层验证配置，并总结：先明确执行环境，优先改名而非覆盖，且要用故障注入确认测试能识别错误。

源站该信谁：给 AI 中转站配上阿里云 ESA 的边缘能力

CDN 回源后，nginx 的 `$remote_addr` 记录的是边缘节点 IP，无法识别真实访客，导致审计、限流和 IP 白名单缺乏可靠身份依据。阿里云 ESA 可通过托管转换注入 `ali-real-client-ip`、地理位置及 `Tls-Hash`，并在 nginx 中信任 ESA 回源网段、读取真实客户端 IP。配置后可完善日志审计、来源限流和风控识别，减少自建 IP 地理库与边缘规则的维护。实测一周 28.7 万次请求，API 中转站占 8.6%，每次调用仍需确认来源可信；该方案更适合访客主要在国内、且源站确实经过 ESA 的站点。

真实 IP 一直在，只是没人用：一个点不动的开关，牵出一个 IP 伪造漏洞

文章排查了中转站启用 Passkey 后的连锁问题：Passkey 同时受 config.yaml 的 WebAuthn 安全配置和数据库运行开关控制，前者必须正确填写 RP ID 与 HTTPS Origin，后者显式为 false 时不会自动开启。登录即掉线源于会话 IP/UA 绑定，而 ESA 回源 IP 每请求变化，触发会话家族撤销。进一步发现 nginx 未还原真实 IP、应用优先信任可伪造的 CF-Connecting-IP，导致审计、限流和 IP 白名单失真并可被绕过。修复包括配置 ESA 官方网段、使用其真实 IP 头、覆盖转发头并限制源站访问；历史 1687 条审计记录中 1681 条 IP 不真实。

把本地 AI 英语学习项目部署到云服务器：我的 Docker 镜像与 1Panel 上线实录

文章记录了将本地 English Learning Agent 部署到腾讯云的完整流程：针对 4 核、3.4GB 内存且无法稳定访问 Hugging Face 的服务器，在开发机构建多阶段 Docker 镜像，预置 CPU 版 torch 与 embedding 模型，再压缩上传并导入服务器。通过 1Panel 编排容器，挂载 SQLite、音频和应用数据，处理非 root 用户权限、密钥与备份，配置域名 HTTPS 反向代理及长请求超时。上线后还需验证健康检查、账号登录、六步学习流程、日志和数据恢复，说明镜像启动不等于项目可用。

CPU 曲线骗了我：一台 2 核 1.6 GiB 无 Swap 的阿里云服务器周期性卡死排障

文章通过系统历史采样还原服务器反复失联的过程：网络与外部攻击并非主因，故障期间磁盘遭遇持续纯读风暴，IO 排队和等待飙升，内存随之承压；机器没有 Swap、多个容器未设内存上限，缓存被不断清理，最终陷入读盘与内存压力相互加剧的循环并硬崩溃。另发现家中设备每约 16 秒 SSH 登录，造成大量会话日志和用户级日志膨胀，但读风暴的发起进程仍未查明。作者启用 zram、调整换页策略并限制日志后，IO 压力、内存和网站状态明显改善；提醒排障应保留现场，故障再现时用 pidstat 定位进程。

从 CI 红灯到 Scoop 分发：PathEditor 5.1.1 的一次发布链路复盘

文章复盘 PathEditor 5.1.1 从质量门修复到发布分发的全过程。项目虽能构建、测试通过，但覆盖率、格式、Clippy 和 E2E 暴露出门禁失效；后续又发现前后端字段命名不一致、验证队列时序丢失、禁用状态跨重启消失、部分保存被误报成功等问题。修复后将发布流程纳入 CI，并通过个人 Scoop bucket 分发 CLI。文章强调：测试通过不等于真实环境正确，必须验证数据契约、状态持久化、安装来源和实际 PATH 命令解析，同时区分 mock、工具链和发布资产的差异。

20 天，170 万次请求——我的阿里云 ESA 数据复盘

基于ESA控制台20天真实数据复盘：区间内累计约170万次请求，日均8万多，单日峰值27.9万；可缓存请求命中率约66%。流量大头是自建Git仓库（100.93万），而非博客（22.45万）；移动、电信、联通均有真实访问，约50.47万次请求被识别为Bot，说明防护确实在承接压力。结论：对国内个人站，阿里云ESA值得用，理由是国内节点就近接入、加速与防护一体化、接入门槛低。后续将继续观察命中率与Bot占比变化。

因为喜欢开源，我用 Halo 写了一个插件并发布到了应用市场

作者因热爱开源，在发现 Halo 后台无深色模式后，亲自开发了深色模式插件并上架应用市场。插件后端用 Java，前端用 Vue 3 + TypeScript，核心集成开源 Dark Reader 引擎，支持浅色、深色、跟随系统三种模式，能记忆偏好并兼容第三方动态内容。开发中借助 AI 工具辅助，但核心思路自定，同时遵守 MIT 许可。经过打磨，规范了设置入口、统一了界面风格，并完善 CHANGELOG、CI 自动发布和依赖安全审计，版本迭代至 1.1.3。插件通过官方审核后上架，包名为 top.liuhangyv.darkmode，任何 Halo 用户可一键安装。作者认为开源是互惠的，鼓励人们从微小贡献开始回馈生态。

我的腾讯云服务器突然烧掉几百G流量？一场与"代码搬运工"的较量

服务器月初流量异常飙高，日均消耗7~20GB，带宽持续满速。通过监控数据发现异常时段，登录排查排除中毒可能，转而检查容器日志，锁定Gitea日志中一天内5.3万行记录、98.6%请求来自同一网段，发现机器人地毯式抓取源码。真正原因并非端口暴露，而是FRP隧道绕过了腾讯云安全组，使内网服务通过阿里云公网域名可达。将Gitea改为仅登录可见后，流量回落至正常水平。经验包括：内网穿透工具等同公开服务，需加强鉴权；日志体积是排查流量大户的关键；匿名可见易招爬虫；应先分析数据和日志，再定位修复。

从 5 个到 17 个：我的 Windows 终端工具链升级记

作者从一句“我的 Scoop 用了吗”出发，发现终端里除了 5 个常用工具，还残留着 14 个断链 shim 和旧配置。原本只想清理，最终升级为一次完整的终端工具链改造。核心方法：先用 AI 调研（Exa 搜索核验 164 条来源），确认 `bat`、`fd`、`fzf`、`zoxide` 仍是主流；用排除法决定“不装什么”，留下 17 个工具并按使用频率分两批安装；装完后配置 PowerShell profile（别名、zoxide、PSFzf、delta、oh-my-posh）实现联动。作者强调，工具不是装完就完事，需在实际场景中验证价值，并沉淀为按用途分类的手册——装 17 个工具不难，难的是知道哪 17 个不用装。