首页 (2) - 码厩

#1178 HTTP Query 方法

Web HTTP 2026-06-28

#1177 将 HTML 内容编码到一个 Favicon 图标中

Web HTML 2026-06-27

我曾经有过一个实验，将文件编码存储到一个图片中。
没有想到还有人想到将网站内容存入一个 Favicon，然后通过 JS 解析出来，有意思。
虽然想不到什么实际意义，但是是一次有趣的探索实验。

Tim Wehrle 的文章《I Stored a Website in a Favicon》是这样说的：
PS：代码放在 GitHub 上。

编码过程：将 HTML 文本转为 UTF-8 字节数组 → 前置 4 字节记录载荷长度（便于截断尾部无用像素）→ 依次写入 PNG 像素的 R/G/B 通道（每像素存 3 字节），生成的图像看似随机噪点。
```
<style>
    body {
        font-family: system-ui;
        max-width: 40rem;
        margin: 2rem auto;
    }
</style>
<h1>Website in a Favicon</h1>
<p>Everything you're reading right now was decoded from favicon pixels.</p>
```
HTML 载荷：208 字节 + 4 字节长度头 = 212 字节
Favicon 部分：选择 9×9 正方形，81 像素，可以容纳 239 字节数据，Cover 上面的 HTML 负载（利用率约 87%）
解码过程：浏览器加载 favicon → 用 Canvas API 绘制并读取像素 RGB 值 → 还原字节数组 → 读取前 4 字节获知长度 → 提取载荷 → UTF-8 解码得到原 HTML → 替换页面内容渲染。
关键限制：favicon 只存内容，仍需一小段外部 JavaScript（bootstrap loader）来解码，无 JS 时它只是一张普通 PNG。

#1176 hosts 文件与 systemd 的域名解析

DNS 2026-06-27

案例复盘：systemd-resolved 合成记录导致 AAAA 解析“幽灵失败”

#1175 HBM 高带宽内存

硬件 2026-06-26

内存厂商生产三种内存：DDR（桌面电脑用的内存）、LPDDR（手机用的低功率内存）、HBM（AI 机房用的高带宽内存）。
由于 AI 公司对 HBM 的需求激增，开出高价，内存厂商的生产能力转向 HBM，减少了 DDR 和 LPDDR 的产量，导致消费电子设备的内存短缺，价格上涨。

第一次知道有 HBM 类型的内存条。

HBM（High Bandwidth Memory，高带宽内存）是一种专为高性能计算设计的先进 DRAM 技术。

与传统内存将多个芯片平铺在主板上不同，HBM 利用硅通孔（TSV）技术将多层 DRAM 芯片垂直堆叠，再通过硅中介层（Interposer）与 GPU、AI 加速器或 CPU 封装在同一封装内，极大缩短了数据传输路径。

HBM 采用 1024 位超宽总线 和较低工作频率，通过“宽总线、低频率”的设计实现每秒数 TB 的内存带宽，同时相比传统 DDR 或 LPDDR 具有更低的单位带宽功耗。

近年来，随着生成式 AI 和大模型训练的发展，GPU 对内存带宽的需求远高于容量需求，HBM 已成为 AI 芯片不可或缺的关键组件。

目前主流产品已发展至 HBM3 和 HBM3E，广泛应用于 NVIDIA、AMD 等公司的 AI GPU，以及高性能计算、超级计算机和数据中心加速器中，其性能已成为衡量 AI 芯片竞争力的重要指标之一。

HBM、DDR、LPDDR 的区别

特性	HBM	DDR	LPDDR
全称	High Bandwidth Memory	Double Data Rate SDRAM	Low Power DDR
主要用途	AI GPU、HPC、数据中心	PC、服务器	手机、平板、笔记本
安装位置	与 GPU/CPU 同封装	DIMM 内存条	焊接在主板或 SoC 附近
芯片结构	TSV 垂直堆叠	平面封装	平面封装
总线宽度	1024 bit	64 bit（每通道）	16～32 bit（每通道）
工作频率	较低	较高	较低
内存带宽	★★★★★（TB/s 级）	★★★	★★
功耗	单位带宽最低	中等	最低（整体）
成本	最高	较低	中等
容量扩展	较困难	最容易	有限

三者定位

DDR：追求容量、成本和可扩展性，适合 PC 和服务器。
LPDDR：追求低功耗，主要用于移动设备和轻薄本。
HBM：追求极致带宽，专门解决 GPU、AI 加速器和超级计算机的数据吞吐瓶颈，其成本最高、封装最复杂，但能够提供传统 DDR 难以企及的内存带宽。

#1174 我的 Token 消耗情况

AI 开发者 2026-06-25

我用的是 Cursor 做开发，根据 Cursor 后台统计，一个月消耗 Token 大约 6 亿 Token。
需要购买 Pro+ 套餐才能满足要求，一个月 48 美金（年付），折合人民币大约 336 元。

听说龙虾的创始人每月消耗 6000 多亿 Token，是我的 1000 倍，确实有点吓人。
哪怕采购量大可以打一折，也得 3 万多元人民币。
PS：他是 OpenAI 员工，可以无限量调用自家模型，不用花钱。

网约车巨头 Uber 今年头四个月就花完了全年34亿美元的 AI 预算，不得不限制使用 AI 了。
微软也因为费用超标，放弃了 Claude Code，改用自家托管的 OpenAI 模型。

听同事讲，公司提供的 Codex 200 刀的套餐，所有研发共用，每月基本上足够。
Codex 200 刀的这个套餐可以这么划算么？我查了 Codex 订阅和相关信息，看起来也不至于这么划算啊。
不知道实际上同事们的使用程度到底如何。

基础认知：

Cusor Tab（代码自动补全）通常不消耗额度，AI 对话/生成能力才会消耗额度
模型价格 × 输入上下文长度 × 输出长度 × 调用次数
其中：输入上下文通常是最容易失控的部分，一定需要控制好。
控制上下文范围，比控制模型选择更重要

草拟了一个控制 Token 消耗的方法：

默认使用 Auto 模型，让 Cursor 根据任务自动选择成本和效果更加平衡的模型。
任务拆解后再交给 AI，不要直接把复杂目标交给 AI，确保问题规模小，描述准确。
让 AI 解决明确的小问题，而不是让 AI 自己探索整个系统。
扫描大量代码 + 生成超长上下文 + 多轮修改 = 快速消耗 Token
我的套餐更适合日常开发修改，不适合让 Agent 长时间承担「全仓库理解 + 多轮推理 + 大范围修改」这类高消耗任务。
所以少说：解决 xx 问题、重构 xx 方案。
精准控制上下文范围，尽可能精准指定代码范围，只把相关代码加入模型上下文。
不仅上下文更小，修改也会更准确一些。
新任务就开启新对话（New Agent），避免长期复用同一个对话。
长期积累会导致上下文膨胀。
保持每个 Agent 任务边界清晰。
定期查看 Dashboard 监控模型使用量和 On-Demand 消耗。

#1173 本站静态资源迁移到公共 CDN

Web 2026-06-24

该博客 码厩（markjour.com） 是一个全静态的站点，部署在阿里云的虚拟主机上。
静态网站最大的优点就是省心，完全不需要什么维护工作，写完文章（Markdown 格式）之后编译（HTML 格式）、上传即可，这个过程是通过自己开发的一个 Python 工具实现的。

但是最近几个月遇到了一个比较头疼的问题：几乎每到月底，最后几天网站无法访问，阿里云那边说是本月流量已超出限制。
以前几年一直没遇到过，流量也没有明显变化，不知道是不是最近调整了统计规则。总之，隔三差五地无法访问就很糟糕。

今天抽空处理一下，我想着将网站使用的一些公共资源 —— 如 Bootstrap、jQuery、Font Awesome 等 —— 都采用前端公共资源 CDN，应该就好了。

PS：其实一开始是采用了前端公共资源 CDN 的，只是因为之前选的那些 CDN 用不了多久就关门了，所以就拿掉了。现在又出现这个问题，没有办法，只好重新采用 CDN 的方案。

#1172 网页对电话号码的处理

Web HTML 2026-06-23

页面上加链接可以点击触发拨号 <a href="tel:+8613800138000">138****8000</a>，这个各浏览器都支持。

不同的是，iOS Safari 自动识别电话号码并注入拨号连接，而 Android Chrome 则没有这个行为。

在 iOS Safari 会自动扫描页面中的数字串（比如订单号、序列号、IP 地址），只要格式“看起来像电话”，就会偷偷把它们转换成可点击的拨号链接：

<a href="tel:1234567890">1234567890</a>

这会导致样式错乱，甚至误触拨号。

解决方案：

全局关闭自动识别：
```
<meta name="format-detection" content="telephone=no" />
```
注意：这是 Apple 私有的规范，并非 W3C 标准。

真正需要拨号的地方，手动声明：

<a href="tel:+8613800138000">138****8000</a>

#1171 华为手机 v2rayNG 连接不上节点

计算机网络 2026-06-14

在一台华为 Nova 9 手机上研究新版本 v2rayNG 运行原理 🐶。
可以正常启动，也能成功更新订阅，但点击连接后没有任何反应，连接按钮状态不会切换。

同一份订阅在另一台华为 Mate 30 手机上运行正常，因此最初怀疑是系统兼容性问题。

查看 v2rayNG 日志后发现报错：

config error: infra/conf/serial: failed to parse json config > infra/conf: failed to build outbound config with tag proxy > infra/conf: failed to build stream settings for outbound detour > infra/conf: Failed to build TLS config. > common/errors: The feature "allowInsecure" has been removed and migrated to "pinnedPeerCertSha256". Please update your config(s) according to release note and documentation.

从错误信息判断，Xray Core 在加载配置时失败，原因是配置中包含已废弃的 allowInsecure 选项。

最初怀疑是两台手机使用了不同版本的 Xray Core，但检查后发现 Core 版本完全一致。

随后分别导出两台设备的完整配置进行对比，发现：

Mate 30:
allowInsecure = false

Nova 9:
allowInsecure = true

虽然订阅来源相同，但本地配置并不一致。

进入 Nova 9 的 v2rayNG 设置后，关闭 allowInsecure 选项，再次更新订阅，问题立即解决。

原因分析

早期 Xray/V2Ray 配置允许使用：

{
  "allowInsecure": true
}

表示跳过 TLS 证书校验。

新版 Xray Core 已移除此配置项，因此当配置中仍包含该字段时，会直接报错并拒绝启动代理核心。

由于核心启动失败，用户看到的现象就是：

App 可以正常打开；
节点列表正常显示；
点击连接无任何反应；
VPN 不会启动；
状态栏没有连接图标。

#1170 Python 类型注解兼容性问题：PEP 649 之前的 forward reference 行为差异

Python 2026-06-10

我本地 Python 版本是 3.14，服务器上 Python 版本是 3.12。
本地可以正常运行的代码放到服务器上执行失败了，排查后发现是类型注解中引用了后面才定义的类。

例如：

class Foo:
    def method(self) -> Bar:   # NameError: name 'Bar' is not defined
        ...

class Bar:
    pass

经过一番调研，发现是不同 Python 版本对 annotation 的求值策略不同（eager vs deferred），导致运行期是否触发 NameError 不一致。

Python 3.14 引入 PEP 649，使 annotation 采用延迟求值机制，从而允许这种写法；而在此之前的版本默认会在函数定义阶段立即求值，因此会报错，除非：

调整定义顺序
采用字符串类型注解

def method(self) -> "Bar":

未来注解语义（Python 3.7+ 即可用）

from __future__ import annotations

参考资料

What's New In Python 3.14 — PEP 649 & PEP 749
annotationlib — 三种注解语义说明（stock / deferred / stringified）
PEP 649 — Deferred Evaluation Of Annotations Using Descriptors
PEP 563 — Postponed Evaluation of Annotations（from __future__ import annotations）

#1169 纳德拉与微软转型

企业管理 Microsoft 2026-06-07

2014 年纳德拉接任微软 CEO 时，微软正处于 PC 时代红利消退、错失移动互联网机遇、内部部门割裂严重的低谷期。他通过文化重塑 + 战略转向 + 开放生态三位一体推动了微软的"大象转身"。

一	二	三	四	五	六	日