年度归档： 2026 年
-
此前 A Tour of Go 课程页手动 AdSense 广告一直使用 Responsive，并曾通过 max-width: 620px 限制广告容器宽度。当时我在自己的 production 人工测试中，经常看到较小的正方形广告，点击“下一页”后也很容易继续出现广告，体感上的展示概率甚至超过 90%。后来为了充分利用桌面端剩余空间，并尝试获得更宽、可能价值更高的广告，我删除了 620px 最大宽度限制。结果却出现了一个很明显的变化：人工测试中实际看到广告的频率大幅下降，体感甚至不到 5%。由于这些只是发布者自己的有限测试，不能直接作为正式填充率结论，我最终没有简单恢复 620px，而是建立 A/B/C/D 四个独立 Responsive AdSense 广告单元，分别测试 336px、468px、728px 和不限制宽度四种方案，各分配 25% 自然流量，并在同一浏览器标签页中保持稳定分组。目前实验已经正式上线，接下来将停止主动测试，让真实自然流量回答不同广告位宽度究竟如何影响展示量和收益。
-
最近几天 Codex 的额度机制连续发生变化。前一次额度自动完全重置后，因为我知道下一次正常的周额度恢复日期还有一段时间，所以一直在主动控制消耗，甚至从 GPT-5.6 Sol 轻度逐步调整到 GPT-5.6 Terra 中、Terra 轻度，并减少一些不必要的 Codex 使用。 昨天休息前，我的周额度大约还剩 44%。没想到今天早上再次查看时，5 小时额度和周额度又全部恢复到了 100%。 自动重置当然是好事，真正让我觉得可惜的是：如果能够提前知道今天还会再重置一次，那么昨天其实完全没有必要如此节省，那部分即将失效的剩余额度本可以转换成更多实际工作效率。 另外，我从新闻中得知 Codex 用户可能获得一次可以自行决定何时使用的完全重置机会，并最终确认自己的账户已经到账。为了减少以后再次出现类似情况，我又创建了一个 Codex 重置预告监控：平时继续正常控制额度，一旦出现可信的 Reset 信号，再临时切换到更积极的使用策略。
-
2026 年 8 月 26 日，我在 Codex 第一周的第一个 5 小时使用周期中连续记录了三次剩余额度。通过对比「5 小时剩余额度」和「一周剩余额度」，可以估算出：一个完整的 5 小时额度大约相当于一周总额度的 15%。为了以后不再反复计算，我把使用规则简化成三个数字：5 小时看 10%，一天看 12%，15% 是 5 小时极限。 后续只需要观察 Codex 界面中的周额度变化，就可以快速判断当前使用速度是否合适。
-
2026 年 8 月 25 日，我继续验证通过 BeWild 购买的 ChatGPT Plus 3 个月套餐第 3 次续订情况。与 7 月 25 日第二个月成功续订不同，这一次 OpenAI 明确提示付款失败，原 PHP 982.14 账单未完成支付。等待 BeWild 客服超过 1 小时后，最终确认是用于向 OpenAI 自动续费的付款方式失效，随后未完成部分退款 ¥150.69。我重新购买 3 个月套餐，新订单一度任务失败，但通过“继续任务”最终完成。OpenAI 原 PHP 982.14 账单随后作废，并生成新的 US$20 已支付账单。等待系统同步后，ChatGPT Plus 恢复正常，并显示下一次自动续订时间为 2026 年 9 月 26 日。本文完整记录 BeWild 3 个月套餐第三个月自动续订失败、退款、重新订阅和 Plus 恢复的全过程。
-
A Tour of Go 的广告优化在方案 B 与 103 页 Prerender 上线后，又进入了一轮真正的生产稳定性收尾。本文按时间线记录了从方案 A 因复杂 DOM 监听与操作而出现难以稳定复现的问题，到方案 B 改用 Angular course view 生命周期管理广告，再到 Prerender、Angular、CodeMirror 交接过程中出现短暂源码空白，以及真实 AdSense 写入 height: auto !important、min-height: 0px !important 导致课程高度塌缩和 footer 提前进入第一屏的完整过程。最终没有恢复复杂的方案 A，而是仅将其中已经验证有效的局部 layout protection 接回方案 B，并通过浏览器回归测试和真实广告展示完成最终验收。
-
A Tour of Go 的 SPA SEO 问题早已存在：对用户来说，103 个课程 URL 明明对应不同内容，但 Google Search Console 曾将多个页面判断为“重复网页，用户未选定规范网页”。这一次在继续优化 AdSense 的过程中，我最终决定为全部 103 个正式课程页生成独立 Prerender HTML，让服务器首次响应就直接包含本页标题、正文、Go 示例源码、canonical 和 description，同时继续保留 Angular SPA、CodeMirror 与 Playground。本文记录了为什么 SEO 与广告上下文理解共同推动了这次 Prerender 实现，以及如何让每个课程 URL 真正拥有独立页面身份。
-
在决定保留 A Tour of Go 原有 SPA 架构之后，广告问题从“要不要整页刷新”转变成了“广告应该放在哪里、又该如何跟随 SPA 页面生命周期”。本文记录了从 AdSense Preview 识别 footer 下方候选广告位，到方案 A 使用 MutationObserver 跟踪 DOM 变化，再到方案 B 将广告直接绑定 Angular route-owned course view 生命周期的完整演进。最终通过 mount() / $destroy / unmount() 管理每一页独立广告节点，并保留 Auto Ads 继续服务其他已正常运行的站点和域名。
-
在排查 A Tour of Go 展示广告始终不出现的问题时，一个看似直接的方案是放弃 SPA，让每一节课程都通过完整页面刷新来简化 AdSense、统计和 SEO。但进一步对比后发现，最大的代价并不是一次性的前端改造，而是长期偏离 golang/website 上游架构，持续增加同步与维护成本。本文结合官方 A Tour of Go 的 SPA 导航、上游 _content/tour/ 目录以及项目自身的 upstream baseline 管理方式，对“保留 SPA”与“放弃 SPA”进行完整权衡，并最终确定：让广告适配 A Tour of Go，而不是为了广告重新设计 A Tour of Go。
-
在 A Tour of Go 多语言站点接入 Google AdSense 后，课程页虽然存在大片视觉空白，但普通展示广告始终没有出现。本文从 Auto Ads 配置、adsbygoogle.js 加载状态以及官方 A Tour of Go 的 DOM / layout 结构入手，分析为什么“页面看起来有空白”并不等于“Google 认为这里存在可插入广告的位置”。最终将问题范围收敛到 A Tour of Go 特殊的左右分栏和交互式页面结构，并引出后续一个更重要的架构选择：是否值得为了 AdSense 放弃原有 SPA。
-
A Tour of Go 日语版 ja-JP 正式上线后，我没有立即开始第三门语言，而是先复盘第二门语言从开发、翻译、质量审核、projection、production 部署到公网验收的完整过程，并将此前依赖临时分析和上下文记忆的环节固化为正式规范。项目新增 NEW_LOCALE_RUNBOOK.md 和 LOCALE_SURFACE_REVIEW.md，明确新增 locale 的统一入口、TranslationUnit 之外的完整语言质量审核、Rendered Surface Acceptance、首次生产部署与日常维护部署边界，以及 glossary 作为全站术语权威来源的职责，为后续第三门及更多语言建立可重复执行的标准化扩展流程。