东东's Blog

Memos: 十一约教练学了几天车

2026-10-07T15:15:05+08:00

驾照是在几年前考下来的，但一直不会开车，这个十一有些时间，想着学习下，后续自驾出行方便很多。

先在闲鱼上找了带车的教练，约了一节2小时的课，价格是一百元元一小时，教练会在指定地点接送，第一天主要熟悉启停，在小区周边练习左转弯右转弯，调头、加速和刹车等。

只在小区转转肯定是不够，于是根据教练的建议又约了三节共计九小时的课。

第二个三小时：教练找了各种类型路口、强化左转弯右转弯、调头等操作，打转向灯并线、开到回龙观那边练习侧方停车。
第三个三小时：开车到翔安北路附近练习 50 KM/h 左右控速，强化变道。
第四个三小时：开车到延庆古长城西路附近，去程走高速开到 80+，练习山路连续转弯，回程走辅路，刚上车时状态一般，回程好很多，转弯时速度适合就不会再三踩刹车减速，手脚眼的协调更自然，加减速和让行等更有判断力。

教练建议有时间再练个两节课，到二三环内路况更复杂的地方开下，以及夜间行车，我感觉先不用了，过两周有时间租车白天出去转转。

轻徒步・北京・延寿寺后山（2026）

2026-10-07T14:11:13+08:00

10.1 当天，想着可别进城了，北京哪里人都会很多。就计划往郊区走走，前些天在 B 站看个 UP 主推荐个入门级的徒步/爬山路线，就出发前往。

坐地铁到达南邵站，这里有去延寿寺的公交车。

今年印象中没坐过公交车，这次的昌 31 路 20 多站，直接起飞。

车上人一直不多，到达延寿寺之前的几站，人多了起来，现在是采摘板栗的时间，他们大多赶早 7 点钟就来捡板栗，5、10 元一位还有 30 元一位的。一对老夫妻花 10 块钱捡了 17 斤。

到了延寿寺站，好不容易挤着下了公交，下车就能看到「延寿圣境」的牌匾，对面是去往延寿寺的路。

此次选择路线如下，是不到三公里的入门徒步线路。

实测难度确实不高，视野开阔，满眼生机绿意

小花朵、小蝴蝶 🦋

还看到几次身法灵活的小松鼠 🐿️

开始登山，我们选择的是右手侧上山，左手边下山的线路。

十一去这些非热门的地方绝对是明智之选，路上没遇到几个人，独享整个后山。

在山顶，视野开阔，眼前就是大黑山。

这个时节太阳没有很晒，阵阵微风袭来特别的畅快。

在山顶坐了有一会儿就开始下山，很多小昆虫都出来了，不知道这是蝗虫还是蚂蚱，看起来正在准备产卵（喂！这是行人步道上啊）。

没走几步看到 ‘小镰刀尊者’

我感觉它正在盯着我

一路都能看着大黑山，我看攻略大黑山也有徒步的线路，但是距离长不少，有机会可是要走走看。

乌鸦迎着夕阳，哇哇的叫着

下山的路上路过一个废弃的小亭子，蜂巢筑在里边，可真会找地方。

整个徒步时间不到两个小时，夕阳西下，到了回家的时候。

非常棒的十一小徒步～完美收官！

学习 Etcd 笔记：启动与基础命令

2026-10-03T16:59:00+08:00

有了 AI，现在学习成本很低，有很多开源项目都很值得学习，先从 Etcd 始。

搭建 Etcd 测试环境

本机电脑有 Docker 环境就好办了，创建 ~/Portable/etcd-launch/docker-compose.yml，内容如下：

services:
  etcd1:
    image: quay.io/coreos/etcd:v3.7.2
    container_name: etcd1
    command:
      - /usr/local/bin/etcd
      - --name=etcd1
      - --data-dir=/etcd-data

      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://etcd1:2379

      - --listen-peer-urls=http://0.0.0.0:2380
      - --initial-advertise-peer-urls=http://etcd1:2380

      - --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - --initial-cluster-state=new
      - --initial-cluster-token=etcd-cluster-1

    ports:
      - "2379:2379"
    volumes:
      - etcd1-data:/etcd-data
    networks:
      - etcd-net

  etcd2:
    image: quay.io/coreos/etcd:v3.7.2
    container_name: etcd2
    command:
      - /usr/local/bin/etcd
      - --name=etcd2
      - --data-dir=/etcd-data

      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://etcd2:2379

      - --listen-peer-urls=http://0.0.0.0:2380
      - --initial-advertise-peer-urls=http://etcd2:2380

      - --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - --initial-cluster-state=new
      - --initial-cluster-token=etcd-cluster-1

    ports:
      - "22379:2379"
    volumes:
      - etcd2-data:/etcd-data
    networks:
      - etcd-net

  etcd3:
    image: quay.io/coreos/etcd:v3.7.2
    container_name: etcd3
    command:
      - /usr/local/bin/etcd
      - --name=etcd3
      - --data-dir=/etcd-data

      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://etcd3:2379

      - --listen-peer-urls=http://0.0.0.0:2380
      - --initial-advertise-peer-urls=http://etcd3:2380

      - --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - --initial-cluster-state=new
      - --initial-cluster-token=etcd-cluster-1

    ports:
      - "32379:2379"
    volumes:
      - etcd3-data:/etcd-data
    networks:
      - etcd-net

volumes:
  etcd1-data:
  etcd2-data:
  etcd3-data:

networks:
  etcd-net:
    driver: bridge

启动

cd ~/Portable/etcd-launch

docker compose up -d

图像01

查看服务启动状态

$ docker compose ps
NAME      IMAGE                        COMMAND                  SERVICE   CREATED          STATUS          PORTS
etcd1     quay.io/coreos/etcd:v3.7.2   "/usr/local/bin/etcd…"   etcd1     28 seconds ago   Up 26 seconds   0.0.0.0:2379->2379/tcp, [::]:2379->2379/tcp, 2380/tcp
etcd2     quay.io/coreos/etcd:v3.7.2   "/usr/local/bin/etcd…"   etcd2     28 seconds ago   Up 26 seconds   2380/tcp, 0.0.0.0:22379->2379/tcp, [::]:22379->2379/tcp
etcd3     quay.io/coreos/etcd:v3.7.2   "/usr/local/bin/etcd…"   etcd3     28 seconds ago   Up 26 seconds   2380/tcp, 0.0.0.0:32379->2379/tcp, [::]:32379->2379/tcp

查看节点健康状态

$ docker exec etcd1 etcdctl \
  --endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 \
  endpoint health
http://etcd2:2379 is healthy: successfully committed proposal: took = 42.461004ms
http://etcd3:2379 is healthy: successfully committed proposal: took = 42.715752ms
http://etcd1:2379 is healthy: successfully committed proposal: took = 44.439445ms

更详细的信息

$ docker exec etcd1 etcdctl \
  --endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 \
  endpoint status --write-out=json

格式化后：

[
  {
    "Endpoint": "http://etcd1:2379",
    "Status": {
      "header": {
        "cluster_id": 9572721052113347000,
        "member_id": 11090874293180130000,
        "revision": 1,
        "raft_term": 2
      },
      "version": "3.7.2",
      "dbSize": 20480,
      "leader": 15904053625288548000,
      "raftIndex": 8,
      "raftTerm": 2,
      "raftAppliedIndex": 8,
      "dbSizeInUse": 16384,
      "storageVersion": "3.7.0",
      "dbSizeQuota": 2147483648,
      "downgradeInfo": {}
    }
  },
  {
    "Endpoint": "http://etcd2:2379",
    "Status": {
      "header": {
        "cluster_id": 9572721052113347000,
        "member_id": 15904053625288548000,
        "revision": 1,
        "raft_term": 2
      },
      "version": "3.7.2",
      "dbSize": 20480,
      "leader": 15904053625288548000,
      "raftIndex": 8,
      "raftTerm": 2,
      "raftAppliedIndex": 8,
      "dbSizeInUse": 16384,
      "storageVersion": "3.7.0",
      "dbSizeQuota": 2147483648,
      "downgradeInfo": {}
    }
  },
  {
    "Endpoint": "http://etcd3:2379",
    "Status": {
      "header": {
        "cluster_id": 9572721052113347000,
        "member_id": 9754871488702160000,
        "revision": 1,
        "raft_term": 2
      },
      "version": "3.7.2",
      "dbSize": 20480,
      "leader": 15904053625288548000,
      "raftIndex": 8,
      "raftTerm": 2,
      "raftAppliedIndex": 8,
      "dbSizeInUse": 16384,
      "storageVersion": "3.7.0",
      "dbSizeQuota": 2147483648,
      "downgradeInfo": {}
    }
  }
]

目前大多都看不懂是干什么的，先不用管，总之 etcd 集群在本机运行良好，先执行几个命令看下。

键值的读写

在第一个节点写入一个键值对：

$ docker exec etcd1 etcdctl put /demo/name dongdong
OK

从另一个节点读取：

$ docker exec etcd2 etcdctl get /demo/name
/demo/name
dongdong

从 Node-2、Node-3 都能读到 Node-1 设置的键值对，在 etcd 中，节点 Node 有专属的称呼：member（etcd 集群里的一个 etcd 实例，本例集群中有 3 个 members）

这里有两个知识点：

"/demo/name" 这样像是目录一样的 Key 写法是常见约定俗成和推荐风格，类似于 Redis Key（module:thing）使用冒号分隔；
Put 命令既可以用于创建，也可用于更新；

$ docker exec etcd1 etcdctl put /demo/name dondone
OK
$ docker exec etcd2 etcdctl get /demo/name
/demo/name
dondone

查询数据统计信息

先写入几条测试数据

$ docker exec etcd1 etcdctl put /demo/key1 v1
$ docker exec etcd1 etcdctl put /demo/key2 v2
$ docker exec etcd1 etcdctl put /demo/key3 v3
$ docker exec etcd1 etcdctl put /demo/key4 v4
$ docker exec etcd1 etcdctl put /demo/key5 v5
$ docker exec etcd1 etcdctl put /demo/key6 v6

查询某前缀下有多少个 Key

$ docker exec etcd1 etcdctl \
  get /demo \
  --prefix \
  --count-only \
  --write-out=fields

输出如下，其中的 Count: 7 跟上文存进入的 Key 数量对的上。

"ClusterID" : 9572721052113345815
"MemberID" : 11090874293180130209
"Revision" : 9
"RaftTerm" : 2
"More" : false
"Count" : 7

看 etcd backend DB 大小

$ docker exec etcd1 etcdctl \
  --endpoints=http://etcd1:2379 \
  endpoint status -w json \
  | jq '.[] | {
      dbSize: .Status.dbSize,
      dbSizeInUse: .Status.dbSizeInUse
    }'

dbSize: backend 数据库文件当前大小
dbSizeInUse: 实际正在使用的数据页大小

监听指键值的变化

$ docker exec -it etcd1 etcdctl watch /demo --prefix

另启终端执行

$ docker exec etcd2 etcdctl put /demo/name dongdong
OK
$ docker exec etcd3 etcdctl put /demo/age 30
OK
$ docker exec etcd1 etcdctl put /demo/name xiaoming
OK
$ docker exec etcd2 etcdctl del /demo/age
1

可以看到监听的终端输出如下内容

PUT
/demo/name
dongdong
PUT
/demo/age
30
PUT
/demo/name
xiaoming
DELETE
/demo/age

两个知识点：

终端 watch 的是 /demo 前缀，不是某一个具体 key；
写请求可以发给任意 member，watch 仍然会看到整个集群最终产生的事件；

Revision 修订概念

获取键值的详细信息

$ docker exec etcd1 etcdctl get /demo/name -w json | jq
{
  "header": {
    "cluster_id": 9572721052113345815,
    "member_id": 11090874293180130209,
    "revision": 13,
    "raft_term": 2
  },
  "kvs": [
    {
      "key": "L2RlbW8vbmFtZQ==",
      "create_revision": 2,
      "mod_revision": 12,
      "version": 4,
      "value": "eGlhb21pbmc="
    }
  ],
  "count": 1
}

重点看几个值：

header.revision:13: 当前 etcd 全局 Revision，etcd 不仅每个 key 有单独维护的版本，整个 KV 存储也有一个全局递增的 revision，发生一次写事务，revision 通常就会向前推进。当前响应所看到的 etcd 数据库状态位于全局版本 13；
create_revision: 2: 表示这个 key 第一次被创建时，etcd 的全局 revision 是 2；
mod_revision: 12: 这个 key 最近一次被修改时，全局 revision 是 12;
version: 4: 当前 key 自创建以来，被写入了多少次；

执行一次

$ docker exec etcd1 etcdctl put /demo/name dongdong

$ docker exec etcd1 etcdctl get /demo/name -w json | jq
{
  "header": {
    "cluster_id": 9572721052113345815,
    "member_id": 11090874293180130209,
    "revision": 14,
    "raft_term": 2
  },
  "kvs": [
    {
      "key": "L2RlbW8vbmFtZQ==",
      "create_revision": 2,
      "mod_revision": 14,
      "version": 5,
      "value": "ZG9uZ2Rvbmc="
    }
  ],
  "count": 1
}

更新了 /demo/name 键的值，revision 按照预期增长 1，create_revision 因为未发生删除重建，所以保持不变，mod_revision 本次这个 Key 就是最后的修改，对应的就是全局的最新版本，和 revision 相等，version 也加一符合预期。

另外值得一提的是 etcd 的 key 和 value 本质上都是字节序列，可以存储二进制数据。etcdctl -w json 会把 key 和 value 用 Base64 编码，以便安全地放进 JSON 字符串里。

从历史版本开始监听

了解了 revision 概念后，可以通过命令从某个时间节点开始获取事件。

$ docker exec -it etcd1 etcdctl watch /demo --prefix --rev=13
DELETE
/demo/age

PUT
/demo/name
dongdong

$ docker exec -it etcd1 etcdctl watch /demo --prefix --rev=10
PUT
/demo/name
dongdong
PUT
/demo/age
30
PUT
/demo/name
xiaoming
DELETE
/demo/age

PUT
/demo/name
dongdong

可以看到 watch 可以获取历史事件（虽说用途不同，但从表象看，感觉跟 Redis AOF 和 Kafka offset 都很像呢 🤔）

为什么能看到过去的事件？ etcd 是 MVCC 存储，每次写入都会产生新的全局 revision，旧版本不会立刻被覆盖，所以可以按 revision 读取历史，也支持 Watch 从某个历史 revision 开始。

历史保存在哪里？历史版本保存在 etcd 的后端数据库里，底层主要是 bbolt 持久化存储。

历史能保存多久？不是固定时间。历史会一直保留，直到被 compaction（压缩）清理。可以手动压缩，也可以配置自动压缩，例如按时间或 revision 数保留。

本篇 etcd 的学习暂到这里，了解了 etcd 的基础功能，接下来看需要看往哪个方向再探索。

消费者知识小课堂（一）为消费者免费提供餐具，是餐厅应当履行的义务

2026-10-03T11:03:00+08:00

前些天在大众点评看到一家位于昌平评分颇高的北京铜火锅餐馆，餐桌上摆放着消毒后带包装的餐具。

几年前我不在意是否收费，直接打开使用，两年前跟我老弟学到一招，可以让店员拿免费的餐具，店员一般都会拿免费的餐具、没有免费餐具也会告知我直接用这个带包装的就行，不收费。

在这个餐馆，店员明确告知没有免费餐具，我再三询问得知必须使用这个收费 1.5 元每套的餐具，在换家店和使用收费餐具之间二选一，饥肠辘辘的我被迫选择了后者，这是我第一次遇到拒绝提供免费餐具的餐馆。

第二天，我拨打 12315 消费者投诉举报热线进行反馈，再之后的一天，我接到工作人员的电话回访，了解我的就餐情况，希望我提供消费凭证，并询问是否有赔付的诉求。

我告知工作人员并无赔付诉求，希望市场监督管理局可以现场去核实情况，让商家遵守规章制度，免费提供餐具。

后续再遇到拒绝提供免费餐具的餐馆，我将现场提醒其不合规，以下是北京地区餐饮案例解读，建议全文阅读并背诵：

政策文件：《餐饮行业不公平格式条款认定详细解读》

概览

“如甲方需减少订席数，须提前十五天告知乙方，否则乙方将按原订席数全额收费。”
“请保管好自己的物品，谨防被盗，丢失本店概不负责。”或“公共场所请您携带好您的随身物品，如有丢失自负。”
“餐厅有权接受或拒绝顾客自带酒水和食品。如果顾客不接受餐厅建议将被视为自动放弃食品卫生投诉权利。”
“消毒餐具工本费一元”或“消毒餐具另收费”
“禁止自带酒水。”
“包间最低消费xx元。”

对于我遇到情况，原文（四、“消毒餐具工本费一元”或“消毒餐具另收费”。）有明确的记录，重点信息摘录如下：

为消费者免费提供餐具，是餐厅应当履行的义务。

向消费者提供消毒餐具，是餐饮企业的法定义务，其也应当承担消毒餐具产生的费用。

餐饮企业不应当把相关费用转嫁到消费者身上。

如果餐饮企业在提供免费消毒餐具同时，又提供收费消毒餐具，由消费者自行选择以满足个性化要求，亦属合理市场行为。

2026-10-04 补充

市场监督管理局打来电话，告知他们已于下午到达现场对商家进行整改，商家已提供免费餐具取用区。同时通过短信发来‘通知书’，为昌平市场监督管理局点赞！

北京・中秋假期的尾巴（2026）

2026-09-27T21:09:00+08:00

中秋三天的假期接近尾声，在家宅了两天，还是出去走走。坐地铁来到雍和宫地铁站，本想到地坛公园逛书市，还没出地铁站就发现不太对劲儿，这人多到离谱，果断放弃地坛公园，往五道营胡同那边走。

依然人多，远离主路往南边儿走，就有很多居民区的胡同，适合转转。

在交道口北二条看到一个雷霆告示：「禁止在此处倒大便」

继续走走，看到老大爷们的聊天角，很有一种破败的动漫风。

北京的中秋时节，树叶都还没有黄，胡同就是不要设置目的地，也不用看地图，走到哪里就去哪里。

三四点钟，有些饿了，想着都到了簋街，索性去胡大饭店尝尝小龙虾。

等餐的时间比较长，3.50 到店，四十多分钟陆续上菜，麻辣小龙虾网上都说很辣，我就选择了蒜蓉口味的。

小龙虾有滋味，肉质比较好，比我前段时间购买的海底捞的小龙虾强 N 倍。香辣猪蹄也出乎意料的很好吃！

买一份龙虾伴侣素面，沾上蒜蓉小龙虾的酱，小龙虾面这不就做好了

胡大饭店是 24H 营业的，目测下午 5 点之后就不要再 walk in，2 人在大众点评上排队会 2 小时起步，3 小时能吃上都算不错。

吃了 9 分饱还没吃完，剩下一些牛蛙和猪蹄打包带走，步行前往雍和宫地铁站的途中，路过同日升粮行，这家店也有些年头，它家的二八酱可以作为北京土特产带回家。

没几步就到了雍和宫，打道回府，抓住了中秋假期的尾巴～

高鲁棒性 API 设计之 Idempotency Key：并发请求与执行一致性

2026-09-24T19:15:00+08:00

上一篇介绍幂等键留下一些问题，幂等键有了，如果两个请求同时到达，应该如何处理？

未仔细考虑过并发问题的代码可能也试图使用缓存进行存在性检验，但两个请求同时到达时，会发生下面的流程。

请求 A：检查 Redis，不存在
请求 B：检查 Redis，不存在

请求 A：执行兑换
请求 B：执行兑换

请求 A：写入幂等结果
请求 B：写入幂等结果

两个请求都通过了存在性验证，走到业务流程，兑换了两次，问题出在这里：

if !exists(key) {
    result := doBusiness()
    save(key, result)
}

exists 和 save 是两个独立操作。从单个请求的视角看，这段代码没有问题：

检查幂等键是否存在；
不存在则执行业务；
保存执行结果。

以并发视角出发，第一步和第三步之间则存在一个明显的时间窗口。

请求 A 检查完成后，请求 B 完全可以在请求 A 写入结果之前，也完成一次检查。于是两个请求都认为「我是第一次请求」。

所以面对并发问题，真正需要保证的是对于同一个 Idempotency Key，同一时刻只能有一个请求获得业务执行权。

原子地 “抢占” 执行权

Redis 的 SET ... NX 很适合完成这个动作。

例如：

SET idempotency:{key} processing NX EX 300

其中：

NX：Key 不存在时才写入；
EX 300：设置 5 分钟过期时间；
processing：表示该请求正在处理中。

这个操作在 Redis 中是原子的，于是两个请求同时到达时：

请求 A：SET ... NX -> 成功
请求 B：SET ... NX -> 失败

只有请求 A 获得执行权，请求 B 不再进入业务流程。

伪代码大概变成：

// 1. 原子抢占执行权
ok := setNX(key, "PROCESSING", 5*time.Minute)
if !ok {
    return handleDuplicateRequest(key)
}

result, err := doBusiness()
if err != nil {
    // 只有能够确认业务没有产生副作用时，
    // 才可以安全释放 PROCESSING。
    //
    // 如果业务结果处于“不确定”状态，
    // 不能简单 DEL，否则重试可能导致业务再次执行。
    return handleBusinessFailure(key, err)
}

// 2. 保存成功结果，并设置更长的结果保留时间
saveResultWithTTL(key, result, 24*time.Hour)

return result

相比之前：

if !exists(key) {
    result := doBusiness()
    save(key, result)
}

原来的 “先检查、再决定是否执行” 存在竞争窗口，而 SET ... NX 将 “检查是否不存在 + 抢占执行权” 合并成了一个原子操作。

但事情还没有结束

如果只做到这里，又会马上遇到几个新的问题，假设请求 A 抢占成功：

SET key processing NX EX 300

然后开始执行业务。

这时请求 B 带着相同的 Idempotency Key 过来了，它发现 Processing Key 已经存在。

注意：这里的 Processing 状态和 SUCCESS 状态，数据 TTL 是不同的，Processing 根据业务可能只有几分钟，而产生结果的 SUCCESS 状态时间会长很多。

问题来了：

这个 Key 是已经执行成功了？
还是正在执行？
还是上一次执行到一半服务挂了？

所以幂等记录至少需要区分 不存在、PROCESSING、SUCCESS

请求第一次到达时，通过 SET ... NX 原子地把状态从 “不存在” 变成 PROCESSING。

业务执行成功后，再把状态更新为 SUCCESS，并保存原请求对应的响应结果。

例如：

{
  "status": "success",
  "http_status": 200,
  "response": {
    "code": 0,
    "message": "success"
  }
}

这样后续相同请求再次到达时，就不需要重新执行业务，可以直接返回第一次请求的结果。

并发请求应该返回什么？

假设请求 A 仍然处于 PROCESSING：

请求 A：PROCESSING
请求 B：再次请求

请求 B 此时有几种处理方式。

一种方式是立即返回：

HTTP/1.1 409 Conflict

例如：

{
  "code": "request_in_progress",
  "message": "A request with the same Idempotency-Key is still being processed"
}

客户端稍后重试即可。另一种方案是服务端短暂等待，请求 A 执行完成后，把 A 的结果直接返回给 B。

例如等待几十到几百毫秒，并轮询 Redis：

B  -> 发现 PROCESSING
   -> 等待
   -> 查询
   -> 等待
   -> 查询
   -> 发现 SUCCESS
   -> 返回 A 的结果

这种方式客户端体验更好，但服务端实现也更复杂，而且会占用连接和计算资源。

实际项目中，更推荐这样判断：

短业务：可短暂等待
长业务：直接返回 processing/conflict，让客户端重试

缓存键一定要设置过期时间

前面的：

SET key processing NX EX 300

必须设置 TTL，因为服务可能在设置完 PROCESSING 后的处理过程中崩溃，如果缓存永不过期，那么这个 Idempotency Key 就永久处于处理中，没人知道它是不是还在运行。

之后所有重试都会被拒绝，本质上也是一种故障恢复机制。

然后就会出现新的问题：如果业务执行时间超过了 PROCESSING 的 TTL 怎么办？

例如 TTL 是 5 分钟：

00:00 请求 A 获得执行权
00:05 Redis Key 过期
00:06 请求 B 到达，重新 SET ... NX 成功
00:07 请求 A 仍然在执行业务

此时 A、B 又同时开始执行了。

所以 TTL 不能简单地拍脑袋设置。

对于执行时间可控的普通 HTTP API，可以让 TTL 明显大于业务正常执行时间。

对于耗时可能非常长的任务，则需要考虑：

延长租约；
定期续期；
将任务转换成异步任务；
或者直接把幂等约束放到数据库事务和唯一约束中。

本文使用 SET ... NX，只是为了原子地确定：谁是这个 Idempotency Key 对应请求的第一次执行者。

Redis 原子，不等于业务原子

还有一个更加重要的问题。

即使 SET ... NX 本身是原子的，也不意味着整个业务流程是原子的。

例如兑换业务：

1. Redis 抢占 Idempotency Key
2. 数据库事务：扣减积分 + 创建兑换记录
3. 数据库 COMMIT 成功
4. Redis 保存 SUCCESS

假设数据库事务已经 COMMIT 成功，但服务在 Redis 保存 SUCCESS 之前崩溃，此时可能出现：

Redis：PROCESSING
数据库：兑换已经成功
客户端：没有收到成功响应

过一段时间 PROCESSING 过期，请求重新执行。

如果业务本身没有其他保护机制，就可能再次扣积分。

所以 Idempotency Key 能解决的是 HTTP 请求级别的重复提交问题，搭配 SET ... NX 能看住服务的大门，内部系统的业务 ‘幂等建设’ 仍需要仔细考量服务可能在任何阶段挂掉后的恢复机制，数据库层增加最终约束进行兜底。

下一篇，仍是关于 Idempotency Key ，还需要继续学习解决一个问题：

如果两个请求使用了相同的 Idempotency Key，但请求参数却不一样，应该怎么办？

Memos: 风云不语，只是一个劲儿的赠送重置卡

2026-09-23T10:17:23+08:00

2026 年 9 月 22 日 Anthropic 发布 Claude Opus 5.5，同时赠送了一张重置卡（引入用户自主点击重置卡）。

同一天，OpenAI 发布 GPT-6 Sol 和 GPT-6 Luna 模型，也赠送了一张重置卡。

Yes 工程师提前过中秋！

Memos: 看着一点也危险

2026-09-22T09:19:23+08:00

早上骑车路过一个施工现场，远远就看到有个人站在渣土车上 ‘观察’，直直的站着，两脚就踩着车斗的两个边框上（比图中更加夸张）。我猜是为了指导挖掘机填土，（如果有）安全员，看了肯定直呼哇塞。

Memos: AI 默默的从 ~/.zsh_history 翻到 token 更新了生产环境

2026-09-15T17:01:23+08:00

我表述想更新 Tag Name，过了一会儿它已经把测试、正式环境都更新好了。

过于‘智能’，问题是我从未配置过生产环境的操作流程、地址和密钥，以至于我看到生产环境已经生效，最后才怀疑到是它干的...

听说过很多 Agent 删数据库、删代码库、删工作区的... 第一次遇到这种翻我命令历史找线上环境地址和 token 自动操作不打招呼的，开眼界了 🤷‍♂️

吓得我赶紧添加了一段约束添加到 AGENTS.md 防一手儿这老小子。

## 外部环境与凭据安全

- **Agent 禁止操作 production**：不得连接、查询或修改线上 API、数据库、缓存、
  主机、集群、云资源、管理后台、部署或任务系统；只读、dry-run、用户已登录或
  用户提供凭据均不例外。
- 即使工具支持 production，Agent 也只能生成并本地验证命令、SQL、脚本和操作步骤，
  由用户手动执行；不得通过 shell、浏览器、子 Agent 或其他方式间接代为调用。
- 外部操作前必须明确环境和实际 host；无法证明是本地、测试或明确允许的隔离环境时，
  一律按 production 处理并拒绝执行。不得从文件名、历史命令或相似域名猜测环境。
- 缺少凭据、登录状态或环境信息属于合法阻塞条件。不得为完成任务而主动读取、搜索、
  解析或恢复 shell history、密码管理器、系统钥匙串、浏览器存储、SSH 身份、
  CLI 认证文件、日志、剪贴板或进程参数中的凭据。
- 泛化授权（如“调用接口”“修改数据”“使用已有登录”）不构成凭据来源授权。
  非 production 操作只能使用用户明确指定的凭据来源或工具约定的标准认证链。
- 不得读取、打印、复制、导出、持久化或跨任务复用秘密值；配置检查只报告
  “已设置 / 未设置 / 可用 / 不可用”。
- 可能触达 production 的工具必须要求显式提供环境、host 和 apply 参数，
  不得自动发现凭据或目标环境；工具能力不代表 Agent 获得执行权限。

非京籍个体户缴纳社保(补充)：Web 端员工工资薪金个税预扣预缴

2026-09-15T11:45:00+08:00

早在几年前，Web 端就支持了单位代扣代缴员工个人所得税，当时参考小红书上的教程，就一直沿用 Windows 客户端的方式缴纳，其实 Web 端缴纳更加方便。

本文是对《非京籍个体户缴纳社保(十)：新增并缴纳个人所得税-工资薪金》一文的补充。

地址：https://etax.chinatax.gov.cn

登录后可以看到 Tab 有「单位办税」的选项，点击进入，在综合所得申报内，可以看到正常工资薪金所得。（员工信息需要重新录入）

而后查看申报信息是否准确，这里刚看到的时候有些奇怪，“应纳税额” 和 “已缴税额” 在客户端好像没这样显示。

不过是正确的(如果暂时不考虑个人承担的社保、公积金，每个月就是：工资收入 6000 − 基本减除费用 5000 − 赡养老人专项附加扣除 950 = 应纳税所得额 50 元（50 × 3% = 1.50 元）

到 2026 年 8 月：

累计收入：6000 × 8 = 48000
累计减除费用：5000 × 8 = 40000
累计赡养老人扣除：950 × 8 = 7600

累计应纳税所得额 = 48000 − 40000 − 7600 = 400 元

累计应纳税额 = 400 × 3% = 12 元

前 7 月已缴：1.5 × 7 = 10.50 元

8 月应缴：12 − 10.50 = 1.50 元

跟之前缴纳数额都是一致的，确认没问题后继续缴款。

选择银联缴纳的方式，缴税款即可。Web 端功能更丰富，查询统计模块支持 “单位申报记录查询” 和 “个人扣缴明细查询”

在单位申报记录查询页面，可以看到有显示 “扣缴客户端web版”，之前的记录都是 “客户端”

2026 北京社保下限上调｜个体户每月最低缴费 2707.44 元

2026-09-10T12:05:16+08:00

自 2026 年 7 月起，北京市职工基本养老、失业、工伤及职工基本医疗保险（含生育）的月缴费基数上限和下限分别为：

上限：36348 元
下限：7270 元

相比 2025 年，下限由 7162 元上调至 7270 元，增加 108 元，涨幅约 1.51%；上限由 35811 元上调至 36348 元，增加 537 元，涨幅约 1.50%。

按 7270 元缴费基数，个体工商户以企业身份为经营者缴纳社保，承担单位和个人两部分费用明细如下：

企业职工基本养老保险：单位 1163.20 元，个人 581.60 元
失业保险：单位 36.35 元，个人 36.35 元
基本医疗保险：单位 639.76 元，个人 145.40 元
职工大额医疗互助保险：单位 72.70 元，个人 3.00 元
工伤保险：单位 29.08 元
合计：2707.44 元/月（较 2025 年增加 40.17 元/月）

作为对比，2025 年社保基数调整后，个体工商户最低缴费由 2540.42 元/月上升至 2667.27 元/月（上涨 126.85 元/月）。

数据来源

Memos: 客户端藏不住接口参数和密钥

2026-09-09T17:00:23+08:00

这两天使用 AI（GPT 5.6 Luna High 模型）做了两个测试：

某不支持导出历史记录的记账软件，我从 2022 年开始使用，已经有不少数据，想拿回来拥有自己的数据。AI 使用模拟器（手动登录账号），静态分析 + 抓包帮我把所有的历史数据下载回来；
某视频 APP，接口请求 Body 使用 AES 加密，提供给 AI xapk 安装包，其纯静态分析和验证，十几分钟后帮我准确找到了 AES Key；

早些年客户端会通过各种奇淫巧技将密钥等信息藏起来，现在感觉意义不太大了，服务安全评估应该假定客户端密钥、接口逻辑均暴露在 Github 上时，服务端是否仍能足够安全。

高鲁棒性 API 设计之 Idempotency Key 幂等键

2026-09-05T21:34:00+08:00

有这样一个场景，客户端调用服务端 API 兑换奖励：

POST /api/v1/redemptions
{
    "reward_id": "id-123"
}

用户发起一次商品兑换请求，因网络等因素，客户端不清楚是否处理成功，可能会发起重试，假设前一个请求在服务端已经成功，只是在返回途中丢失，客户端重试时，服务端没办法判断是客户端重试还是用户发起的第二次兑换请求。

结合业务场景，以下方式可能在一定程度上缓解问题，如：

这个商品一个用户生命周期只能兑换一次；
在一定间隔内，粗暴的根据 Body 请求内容去重，需要琢磨间隔时间，会在一定程度上误伤正常请求；
躺平、无视小概率场景，用户要是有疑问就找客服同学反馈...

行业内正规的做法是借助 Idempotency Key 幂等键，其解决的问题正是客户端在无法确定上一次请求是否成功时，可以安全重试，而不会重复产生业务副作用。

幂等键由客户端传递，标识客户端的一次业务意图，同一次业务意图的重试必须复用同一个 Idempotency Key。用户再次主动发起同类操作时，则生成新的 Key。

常见的幂等标识携带方式大致有两类。第一类是作为 API 请求参数的一部分：

POST /api/v1/redemptions
{
    "reward_id": "id-123",
    "idempotency_key": "the-idempotency-key-dhfa"
}

例如 Google AIP-155 定义了 request_id，AWS EC2 部分 API 则使用 ClientToken，它们都承担了类似 Idempotency Key 的作用，在 JSON REST API 中，这类参数也经常体现在 Request Body 中。

另一类是放到 Header 中。近年来，更多新设计的 API 选择这种方式，例如 Stripe、PayPal、IETF 草案（目前已过期，尚未成为 RFC）

POST /api/v1/redemptions
Idempotency-Key: the-idempotency-key-dhfa
{
    "reward_id": "id-123"
}

我个人感觉通过 Header 的方式更好，对请求体的结构没有侵入性、Header 便于通过中间件统一处理、Idempotency Key 从语义上看也适合作为基础字段。除非业务上完全没有幂等需求，或仅几个接口需要特殊处理才考虑使用 Body 携带，否则新项目设计 API 建议通过 Header 携带幂等键。

幂等键的推荐值

建议使用 UUID v7 或 UUID v4。v7 是时间戳 + 随机数，按时间大致有序，v4 基本纯随机，都比自己生成随机数更稳定通用。

同时应限制 Idempotency Key 的最大长度，比如参考 Stripe 其限制不超过 255 个字符，对于要求提供 Idempotency Key 的接口，缺失、格式非法或超长可以返回 400 Bad Request。

幂等记录的作用范围和时效性

回到服务端的实现，为了识别重复请求，需将首次请求的 Idempotency Key 及其处理状态、请求参数指纹和业务结果记录。可以借助 Redis 缓存存储，一般使用 Authenticated User + HTTP method + Endpoint 组合作为 Idempotency Key 作用范围是比较合理的，以下是 Redis 缓存 Key 的结构示例：

idempotency:{user_id}:{method}:{route}:{idempotency_key}

也就是

idempotency:USER3366:POST:/api/v1/redemptions:01a070a1-33bf-72ae-9e60-95f5e0fc3f82

缓存 Key 直接包含接口路径可能会比较长、不美观也不便于查阅，可以给接口定义 ID，例如 redemption.create，idempotency 也可简化。

idemp:USER3366:redemption.create:01a070a1-33bf-72ae-9e60-95f5e0fc3f82

缓存时间则没有统一的标准，一般建议缓存 24 小时，也有平台缓存 7 天，像是支付、转账、订单等场景更推荐将幂等记录持久化到数据库，并对 “作用域 + Idempotency Key” 建立唯一约束。如果仅仅为了解决短时间重试、重复点击问题，可以将缓存设置为几分钟，但并发场景需要原子化处理，并发问题等下篇再记录。

另外也可以在中间件上做文章，按接口的重要程度设置不同的缓存时间或持久化存储策略。

遇到 Idempotency Key 重复后的返回内容

上方设计了缓存键，能否将 Response Body 保存下来，相同的重复请求正好从缓存直接返回呢？

可行，但需慎重，可以保存首次请求的完整处理结果，包括请求的用户（防止撞到别人的 key 读回别人的响应体）、参数指纹、HTTP 状态码、必要的响应头和响应体，后续相同 Key 且参数一致时，返回相同结果。

当请求的 Idempotency Key 相同，但 Request 不同时，应识别并抛出 422 Unprocessable Content 错误。

# Request Fingerprint 是基于规范化后的、与业务语义相关的请求参数生成的指纹。
fingerprint(new_request) != fingerprint(original_request)

Stripe 也有类似的设计，明确会比较后续请求参数和原请求参数（Docs）防止误用，AWS 也有非常类似的 IdempotentParameterMismatch。

返回错误的响应示例：

{
  "code": "IDEMPOTENCY_KEY_REUSED",
  "message": "Idempotency key has already been used with different request parameters."
}

简单来说，Idempotency Key 判断 “是不是同一次业务意图”，Request Fingerprint 判断 “客户端是不是拿同一个业务意图 ID 偷偷换了请求内容”。

另外的要点

了解以上内容，接口幂等键的设计就不会有大方向上的问题了，但对于幂等键，还有一些需要掌握的。

幂等与幂等键

不要混淆，两者是不同的概念。

幂等：同一个操作执行一次和执行多次，最终效果相同（GET、HEAD、OPTIONS、PUT、DELETE 等方法在 HTTP 语义上是幂等的，而 POST、PATCH 等方法的 HTTP 语义不保证幂等，参考 RFC 9110）。
幂等键：幂等键是为了让原本不幂等的操作获得幂等能力，是实现幂等的手段。

适用的 HTTP 方法

幂等键主要用于 POST、PATCH 等 HTTP 语义本身不保证幂等的方法，GET、HEAD、OPTIONS 通常没有必要使用；PUT、DELETE 按 HTTP 语义本身已经幂等，但具体 API 仍可能使用幂等键提供额外的请求去重、结果重放等能力，应以 API 的具体定义为准。

Stripe 文档有这样的描述：「Don't send idempotency keys in GET and DELETE requests because it has no effect. These requests are idempotent by definition.」（不要在 GET 和 DELETE 请求中发送幂等键，因为这样做不会产生任何效果。这些请求根据定义本身就是幂等的。）

关于幂等键的记录，就先到这里。

Memos: 终于、用上了 Google AI Pro 套餐

2026-09-03T19:04:23+08:00

两个月前在闲鱼购买了个 18 月的 Google AI Pro 订阅，使用小号领取。

而后下载 Gemini Cli，登录后网页提示验证，提示需要输入手机号，一直没办法通过验证，就闲置下来，Google 发了新的 Gemini 3.8 Flash 模型听说不错，想着再试试，下载 Antigravity Cli，走登录流程、提示扫码，验证成功。

重点：

优先使用 Antigravity Cli 进行认证，而非 Gemini Cli（后者感觉是残次品）；
网页弹出手机扫描验证的时候，使用手机自带的相机扫码，而非 Google 家的应用，后者会让发短信，发短信会失败；

Memos: 推荐试试 oh-my-pi Agent

2026-09-02T18:10:23+08:00

同事推荐的，我下载试了试，可以连接到 ChatGPT、Cursor、Claude..及各种订阅，使用其订阅额度。

相较于 ChatGPT（Codex），使用同样的 OpenAI 的 5.6 Luna High，OMP 运行流畅、速度更快。

Github 仓库：can1357/oh-my-pi

Memos: 新计费模式下的 Cursor Team $40 已无开通必要

2026-09-01T10:35:00+08:00

本月公司订阅的 Cursor Team 计费方案变更，从按次每月 500 点数变为按量计费 $20 额度。$ 40/人的席位费包含 $20 额度，Cursor 真想得出来 🤷‍♂️

之前使用 Codex + Claude 出详细实施方案，然后用 Cursor 内的 Composer 2.5 Fast 或 Claude Opus 4.6 High 能实现个七七八八，一次任务消耗 2 个点，500 点数用光后还有 Auto 模式可以继续用，性价比超高。

新的计费模式下几天就能耗光月额度，体感可用量变为原来的 1/10 不止。

P.S. 让 AI 查看新旧计费方案下的详细 Usage CSV，新 $20 按当前消费速度只能用约 6 天，旧 500 次按当时请求速度约能用 33 天。

Redis 集群模式下使用 MGET 触发 CROSSSLOT Keys

2026-08-31T21:00:00+08:00

说来惭愧，今天我才了解到 Redis Cluster 模式下 MGET 的使用 “陷阱”，起因是翻日志看到 Redis 请求报错日志：

(error) CROSSSLOT Keys in request don't hash to the same slot

定位到是 Redis 命令 MGET 抛出，简单说就是 MGET 在 Redis 集群模式下获取多个数据，如果这些 Key 没有哈希到同一个 Slot 就会报错。

那么怎么让需要批量获取的数据在一个 Slot 呢？使用 Hash Tag，先看未使用 Hash Tag 的错误示例：

127.0.0.1:7000> set app:article_meta:id-1 1
-> Redirected to slot [10828] located at 127.0.0.1:7001
OK
127.0.0.1:7001> set app:article_meta:id-2 2
OK
127.0.0.1:7001> set app:article_meta:id-3 3
-> Redirected to slot [2574] located at 127.0.0.1:7000
OK
127.0.0.1:7000> mget app:article_meta:id-1 app:article_meta:id-2 app:article_meta:id-3
(error) CROSSSLOT Keys in request don't hash to the same slot

复现出线上遇到的错误，而后在 Set 的时候使用 Hash Tag 试试。

127.0.0.1:7000> set app:{article_meta}:id-1 1
OK
127.0.0.1:7000> set app:{article_meta}:id-2 2
OK
127.0.0.1:7000> set app:{article_meta}:id-3 3
OK
127.0.0.1:7000> mget app:{article_meta}:id-1 app:{article_meta}:id-2 app:{article_meta}:id-3
1) "1"
2) "2"
3) "3"

使用 Hash Tag 标记 article_meta 后，这三个 Key 都会在一个 Slot 中。

问题很好解决，值得思考的是程序在设计缓存时，能否考虑到外部缓存服务的差异？当下的做法，我将这个问题添加到了 Code Review Skills 检查项中，避免再次被引入。

另外的信息：

Redis Cluster 默认使用完整 Key 计算 Hash Slot。当 Key 中包含 {...} 时，只会使用花括号中的内容计算 Slot。因此上例中的三个 Key 都使用 article_meta 计算 Slot，从而保证位于同一个 Slot。需要注意，Hash Tag 也意味着这些 Key 会集中到同一 Slot，在数据量较大的场景下需要关注热点和数据分布问题。

烹饪日记：干煸蚕蛹

2026-08-30T22:03:00+08:00

（害怕蚕蛹的小伙伴不建议阅读本文）

｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜
｜安全区
｜
｜
｜
｜
｜
｜
｜
｜
｜

前些天在淘宝买回来一些东北的黑蚕蛹，一斤价格 56.8，顺丰包邮。

因为一直冷链，蚕蛹看着都在冬眠，刚收到蚕蛹没时间做，就先放到冰箱中冷藏，又放了两三天担心坏了，就用水煮熟冷冻。

从箱子中一个个取出来

用清水清洗几遍

用水焯个大几分钟，使其完全熟透，中途发现有两个煮熟后蛋白质颜色发黑的扔掉，健康的漏蛋白质蚕蛹可顺手吃掉。

我把蝉蛹装进两个保鲜袋，可以做两顿，自然放凉后放到冰箱冷冻层。

这周末终于有时间做来尝尝，准备好葱姜蒜、花椒和辣椒（先把蚕蛹放到冷藏自然解冻，表面的水渍擦干用空气炸锅烤几分钟使其干燥口感更佳，炒的时候也更省时间）。

起锅将配料爆香。

放入干爽的蚕蛹翻炒，中火炒个几分钟，然后放一点点生抽，放比平时做菜多一些的盐，再放一些孜然。

我炒出来后尝了下，味道还不错，第一次做，炒制时间还是太保守，外皮不脆，感觉再炒个 3、5 分钟脆脆的会更香。

还有一袋，过几天再做着试试。

体验 Age + SOPS 的轻量化配置文件加密方案

2026-08-29T11:49:00+08:00

前两天从 AI 那里听说 age + SOPS，不了解，学习看看。

安装 age & SOPS

age 是使用 go 编写的现代、简单的文件加密工具，主打易用和安全，支持用 age 原生密钥、SSH 密钥等对文件进行加密解密，它常作为 SOPS 的底层加密方式之一，负责真正完成密钥加密和解密。

$ brew install age sops

查看版本

$ age --version
v1.3.1

$ sops --version
sops 3.13.3 (latest)

使用 age 加解密文件

生成加解密用到公钥、私钥。

$ age-keygen -o key.txt
Public key: age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru

打印出来的 age14t32rzna4... 即公钥，可以分发，私钥存放在 key.txt 中，应该妥善保管，不能泄露。

以下是 key.txt 文件内容的示例：

# created: 2026-08-29T08:55:01+08:00
# public key: age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru
AGE-SECRET-KEY-1LHSCMTGXMWC5229EXTMELTVQPQ0C05ADC5W5FWE6VH8CSMFGTRXS0RM98M

加密

$ echo 'hello world' > hello.txt

$ age -r age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru hello.txt > hello.txt.age

在当前目录会生成 hello.txt.age 加密后的文件，内容如下：

age-encryption.org/v1
-> X25519 tTkSP4qyuUXckkhXBHAqn7eEew6PBH4bRwpwouxccko
OtWK+IwbXZy26BAyv/pdHxjyl3pN2UdpqfBkXwtbayQ
--- Z7PzqnySRHiVm3wQoylR3Fn2SYForQgz1C11PuWq0pQ
ú$<8c>æ<9b>;¹<9d>U-SCz+Ó<91>[¦FB¿<83>ÄBQ<9d>©zM%½¯<90>`ù/Û^K¸a^^4Ár

解密

$ age --decrypt -i key.txt hello.txt.age > hello.dec.txt

解密后的 hello.dec.txt 内容等同于 hello.txt

使用上很简单，对 age 了解这么多就好，另外可以思考下：

age 相较于传统强大的 GPG/OpenPGP 解决了什么问题？~~使用简单、密钥对简洁、更少的历史包袱、更适合脚本和 DevOps 工具~~
age 能使用 ~/.ssh 目录下已存在的密钥对吗？~~格式上能兼容使用，但不推荐不同用途的密钥对混用~~

SOPS：Secrets OPerationS

它是专门用来安全管理配置文件中敏感字段的加密工具，没有它的保护，硬编码密钥的配置文件看起来是这样的：

config.yaml

s3:
  endpoint: https://s3.example.com
  bucket: my-app-backup
  access_key_id: AKIAEXAMPLE123456
  secret_access_key: example-secret-access-key

postgresql:
  dsn: postgresql://app_user:example_password@db.example.com:5432/app_db?sslmode=require

配置文件有 N 种可能被泄露的方式，接下来看使用 SOPS 加密后的配置文件：

$ sops --encrypt \
    --age age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru \
    config.yaml > config.enc.yaml

config.enc.yaml

s3:
    endpoint: ENC[AES256_GCM,data:oDPGD9bCSlNAaOtXCprzFhTQfkUleA==,iv:wyyPhrb+xhIe6mtR0yovlEtjZu8PYhay+XJmbavTF8A=,tag:m6jCarHl9+qxNHzS+X1OMw==,type:str]
    bucket: ENC[AES256_GCM,data:hE+oekVYvoedDx1fNw==,iv:IVcGNeOQeZzZmsmvXI8t3QLtV0bdGioctx9bDRAeujo=,tag:579Jhc/rJ4Au+HeynwVlCg==,type:str]
    access_key_id: ENC[AES256_GCM,data:cPax5qWeGuCEVDps7aCTuIU=,iv:8nAjb1/ObTWw0AxGc88dxGF/F6/o4Le6jXmFJNN+vo0=,tag:FKi8FVthEGb4tzKBZXAU7Q==,type:str]
    secret_access_key: ENC[AES256_GCM,data:tzH26GxxIPmuIqQz7ubmMjeeVMhtt9pp6w==,iv:sDl1HoPiprQv5iklT7ayKxyZwoECOlQzyiG7h95kpdU=,tag:p485EjV9fOIG8IOZiJFjNQ==,type:str]
postgresql:
    dsn: ENC[AES256_GCM,data:biJkveus/ptrJYqpHVGLayn+s6kaYZeztuxjjlzEhh/qaByea81tIgXHVsd/yqATAaWIMeI9G947fHfBZwmHMv53c59noIbk/G6uhGFw7ZPb,iv:3e2HFFJbEzWfpXgFsAUR8OdMhj4GPncy6m73Yh8iXZc=,tag:3oanfjNud5lRw94pf9P3qA==,type:str]
sops:
    age:
        - enc: |
            -----BEGIN AGE ENCRYPTED FILE-----
            YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBna1dPaDNnYzFpbUx0RmJF
            RW9vcUZwUnA0aDBvTXVzZlViWmdnUWkvbmxjCkVPN29HeklvU0VEUXRYOUdtbFlT
            Y3kvdVRYbXRXdHlJMGJnSytwOUd0WncKLS0tIFJXTlRMRnFUcWh6MVk5TzVJekZZ
            TTg3UU5rQVQ2S29vMWdMemtKZHY1M1kKSUFPo0k+vPCOktIyDYAr+G7iAndE2yGO
            Ks7i2EIevHNBeWZJP5fOVR0jB0iHICbYlaYkAv3a0vZ7inHYQ90X8g==
            -----END AGE ENCRYPTED FILE-----
          recipient: age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru
    lastmodified: "2026-08-29T01:34:08Z"
    mac: ENC[AES256_GCM,data:eC5Ix0QYRQUe3s2IVq21e4ZQDgig5vfIKfqYhlBhBN0hhMn93K5WU9MjEUSqlq3VbUNXkBw1MlhOGDw2sLC3mkvcah+G08V2rTB9InIy74M8RxiorFaBmUKsgq4tzRrUxSX0/k9FMo5UtJwOFZlr+J/SxmPie9haJD/e1YYf0/4=,iv:839fq/lqbjguY5ehJuAU53QhsyJeohuXk1NjJ46yxoo=,tag:5uQxMofwIhi4qhYlAWcqsw==,type:str]
    unencrypted_suffix: _unencrypted
    version: 3.13.3

可以安全感满满的提交到 Git 仓库中了，解密需要先将私钥文件设置环境变量

$ export SOPS_AGE_KEY_FILE="$PWD/key.txt"

# 或直接设置 KEY 内容
$ export SOPS_AGE_KEY="$(cat key.txt)"

解密

# 打印到终端
$ sops --decrypt config.enc.yaml

# 输出到文件
$ sops --decrypt config.enc.yaml > config.dec.yaml

以上的命令是默认的全配置文件加密，实际使用上只会对特定字段进行保护。使用正则表达式：

$ sops --encrypt \
    --age age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru \
    --encrypted-regex '^(secret_access_key|dsn)$' \
    config.yaml > config.enc.yaml

密文变为

s3:
    endpoint: https://s3.example.com
    bucket: my-app-backup
    access_key_id: AKIAEXAMPLE123456
    secret_access_key: ENC[AES256_GCM,data:iqeYDj2XeR1Nen1amnnX4CHly7ecdvDFJw==,iv:KuitwA6pFNVGmcXpebm5ww2gmvCg48fMA8Ly5YoYOss=,tag:Hvpe8VhjXWEUKeNpfZn3nA==,type:str]
postgresql:
    dsn: ENC[AES256_GCM,data:cXhMxahcKvzzVCljQoAwDkZAn6kosuKKajz+hCurOK4oObgLNDe7lWzPSZyCOgCyvokh/ndmTzxszQJmuwX181FRgGDf6A6OWhuiBAoo2J6y,iv:rEBpzK9EIz/qhKwEeRsiPfKsCRnjqjfbdqZZgftWb6M=,tag:gWiXCVHTPERQBhR/1gdcnA==,type:str]
sops:
    age:
        - enc: |
            -----BEGIN AGE ENCRYPTED FILE-----
            YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBqb0IvbFdiRjE0UXNCTUUx
            WnA1R1lyTFVkMVdma3ZGS2V6QUhpanhjcHk4CnBmdVI0S2d3c1BzaVZ1NlhzaU91
            ZHVZdk95SVdNQUZIeGRBTWdjU1YvOG8KLS0tIHp0Vmh3bjFCMkVzT3dKUWFIZ2ln
            UUZ0aUwvazRpVWttNFRWT0JBSUNuYjAK7z+A8k1ieZS9T5jgsL08Qh9xxYBdhDC3
            7lYjTrbHAS0Ln5/H4jaLsjznVaa+COAgiUP1aRll5ttrxSarYaVPkg==
            -----END AGE ENCRYPTED FILE-----
          recipient: age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru
    encrypted_regex: ^(secret_access_key|dsn)$
    lastmodified: "2026-08-29T01:44:08Z"
    mac: ENC[AES256_GCM,data:MEPLH/+uflaeYsbklr4eEqV3g64jf94LnsSShPoZH++FPy3YuYMaWQDHFFJSXcwrfXa1WlzZN2LWycSGPpkjrtQA31D4CDn8DR2tzV9gJyfIupQa0ZQV+6SVft1Y4vRy7AahZ39WjD/78LZVmr8LkDn+1Z/77IrHHLgTdnQWqrY=,iv:aWF4zNVqpVoPrCGHcUHR7/MZ2jydg5mbgpjpjYuwAfQ=,tag:UZ5rTYwegNShXTwgKvc5Tw==,type:str]
    version: 3.13.3

这样，配置文件仍适合人类阅读，仅密钥相关字段被加密，在项目中使用，可以把加密字段的配置添加到 .sops.yaml 中

creation_rules:
  - path_regex: config\.yaml$
    age: age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru
    encrypted_regex: '^(secret_access_key|dsn)$'

实际使用也会遇到另外的问题：

Git 仓库中提交的是加密的配置文件，是 config.yaml（SOPS 加密）还是 config.enc.yaml 呢？SOPS 推荐 config.yaml
本地电脑启动服务的时候，需要将 config.yaml（SOPS 加密）解密到临时文件供程序读取，或者 sops -d config.yaml | ./app 然后程序从 Stdin 读取，我更倾向于前者

SOPS 轮换密钥对

假如你的私钥 key.txt 不小心被 AI 读取提交到了远端，你担心泄露，那么可以生成新的密钥对替换。

根据建议，SOPS 加密文件本身就叫 config.yaml，不用额外加 .enc。先做一点调整，用之前生成的 config.enc.yaml 覆盖 config.yaml

$ mv config.enc.yaml config.yaml

生成新的密钥对

$ age-keygen -o new-key.txt
Public key: age1qz0sk8u6xktawtxdrve3le4mga89y8qvztgg53p24wkq8mz3hvesqv0udp

修改 .sops.yaml 配置替换公钥（如果你在之前的步骤有创建）

$ sops updatekeys config.yaml

输出

2026/08/29 10:15:20 Syncing keys for file /Users/Username/config.yaml
The following changes will be made to the file's groups:
Group 1
+++ age1qz0sk8u6xktawtxdrve3le4mga89y8qvztgg53p24wkq8mz3hvesqv0udp
--- age14t32rzna4zfd4wen58k4cdeqfe4c34xn826626s8dkd4evhkha3su4wqru
Is this okay? (y/n):

这里提示是否替换，输入 ‘y’

接下来直接执行 sops --decrypt config.yaml 预计会失败，因为配置文件已更新，环境变量使用的仍是旧的私钥。

Failed to get the data key required to decrypt the SOPS file.

Group 0: FAILED
  age1qz0sk8u6xktawtxdrve3le4mga89y8qvztgg53p24wkq8mz3hvesqv0udp: FAILED
    - | failed to create reader for decrypting sops data key with
      | age: no identity matched any of the recipients. Did not find
      | keys in locations 'SOPS_AGE_SSH_PRIVATE_KEY_FILE',
      | 'SOPS_AGE_SSH_PRIVATE_KEY_CMD', 'SOPS_AGE_KEY', and
      | 'SOPS_AGE_KEY_CMD'.

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.

设置新的私钥：export SOPS_AGE_KEY_FILE="$PWD/new-key.txt"

然后再次解密：

$ sops --decrypt config.yaml

打印出了我们原始的配置文件

s3:
    endpoint: https://s3.example.com
    bucket: my-app-backup
    access_key_id: AKIAEXAMPLE123456
    secret_access_key: example-secret-access-key
postgresql:
    dsn: postgresql://app_user:example_password@db.example.com:5432/app_db?sslmode=require

打开加密后的配置文件，可以看到这样一段：

sops:
  age:
    - enc: |
        -----BEGIN AGE ENCRYPTED FILE-----
        ...
        -----END AGE ENCRYPTED FILE-----
      recipient: age1qz0...

这里的 enc 块是用 age 公钥加密后的 SOPS data key

SOPS 随机生成 data key
        ↓
用 data key 加密 secret_access_key / dsn
        ↓
再用 age recipient（公钥） 加密 data key
        ↓
把 “加密后的 data key” 存到 sops.age[].enc

说了这么多，就是说变更密钥对后，data key 也是建议轮换的，我们可以执行以下命令获取到原始的 data key

$ yq -r '.sops.age[0].enc' config.yaml \
    | age --decrypt -i new-key.txt \
    | xxd -p -c 256

执行后输出：98a1a5c148e19199d511ddf93f2d0c3c60cc0bc36edaf2305b040e03ef33c1a5 （256-bit data key）

执行以下命令生成新的 data key 并重新加密字段，执行后再次执行上方命令会获得新的 data key

sops rotate --in-place config.yaml

配置文件字段的加密算法

上方我们获取到 data key，了解 SOPS 是用这个 key 来进行实际的加解密，那猜测大概率是 AES 加密，翻到示例配置文件得到被加密的字段

secret_access_key: ENC[AES256_GCM,data:85KAPsMp1aaqIOM7L1xnLvOys6Dm+Pub3w==,iv:KuitwA6pFNVGmcXpebm5ww2gmvCg48fMA8Ly5YoYOss=,tag:x+ESVatZQIJk2UEWH9SInA==,type:str]

AES256_GCM 表明是 AES，GCM 是 AES 的一种工作模式，全称是 Galois/Counter Mode（伽罗瓦/计数器模式），256 是使用 256-bit 密钥，跟上方获取的 data key 长度一致。

我们有了数据字段，有了 data key，可以自己写脚本解密数据：

package main

import (
    "encoding/hex"
    "fmt"
    "log"

    sopsAES "github.com/getsops/sops/v3/aes"
)

func main() {
    // SOPS data key：32 bytes / 256 bits
    dataKeyHex := "98a1a5c148e19199d511ddf93f2d0c3c60cc0bc36edaf2305b040e03ef33c1a5"

    // 最新的 SOPS 加密字段
    encryptedValue := `ENC[AES256_GCM,data:85KAPsMp1aaqIOM7L1xnLvOys6Dm+Pub3w==,iv:KuitwA6pFNVGmcXpebm5ww2gmvCg48fMA8Ly5YoYOss=,tag:x+ESVatZQIJk2UEWH9SInA==,type:str]`

    // YAML 路径：
    //
    // s3:
    //   secret_access_key: ENC[...]
    //
    // SOPS 将路径作为 AES-GCM 的 AAD
    additionalData := "s3:secret_access_key:"

    dataKey, err := hex.DecodeString(dataKeyHex)
    if err != nil {
        log.Fatalf("decode data key failed: %v", err)
    }

    if len(dataKey) != 32 {
        log.Fatalf("invalid data key length: %d bytes", len(dataKey))
    }

    cipher := sopsAES.NewCipher()

    plaintext, err := cipher.Decrypt(
        encryptedValue,
        dataKey,
        additionalData,
    )
    if err != nil {
        log.Fatalf("decrypt failed: %v", err)
    }

    fmt.Printf("plaintext: %v\n", plaintext)
}

执行输出

$ go run main.go
plaintext: example-secret-access-key

打印出的内容正是上方配置文件 secret_access_key 字段值，所以 data key 也不能泄露。

其它 sops 特性和使用方法

直接编辑加密文件

$ sops config.yaml

获取部分解密后字段值

$ sops -d config.yaml | yq '.postgresql.dsn'

SOPS 不仅支持 age 还支持其它加密平台和方案、多人协作的仓库如何管理，都值得实践，等有使用到再探索。

本文只是了解和体验，就先到这里。

使用 EdgeOne CDN 加速 Immich 地图加载速度

2026-08-19T13:24:00+08:00

前段时间领取 EdgeOne 的免费版使用，其安全加速流量和安全加速请求均显示 ‘不限量’，堪称国内的小赛博罗汉。

本篇记录 Immich 地图瓦片和 Style JSON 文件的配置过程，主要有两项：

使用 EdgeOne CDN 加速 Immich Tiles 地图瓦片数据；
使用 EdgeOne Functions 替换 Style JSON 文件内的资源引用地址；

配置 CDN

创建两个子域名，对应关系如下：

immich-tiles.yasking.org  => tiles.immich.cloud
immich-static.yasking.org => static.immich.cloud

P.S. immich-tiles 和 immich-static 为自定义的子域名，另外手动启用 HTTPS（自动申领或上传自有证书）

访问 Immich 地图配置页面

Console -> Administrator -> Settings -> Map & GPS Settings

将 URL 修改为 CDN 绑定的域名，保留 Path（如上图所示）。

配置 EdgeOne Functions

如果你打开上方路径的 .json 可以看到其内部仍是官方资源硬编码的资源地址

可以借助 EdgeOne 边缘函数对 Host 进行替换，新建函数，内容如下：

async function handleRequest(request) {
  const url = new URL(request.url);

  // 仅允许代理 Immich 的 style JSON
  if (
    url.pathname !== "/v1/style/light.json" &&
    url.pathname !== "/v1/style/dark.json" &&
    url.pathname !== "/v1.json"
  ) {
    return new Response("Not Found", {
      status: 404,
    });
  }

  const upstreamUrl =
    `https://tiles.immich.cloud${url.pathname}${url.search}`;

  const response = await fetch(upstreamUrl);

  if (!response.ok) {
    return response;
  }

  let text = await response.text();

  text = text
    .replaceAll(
      "https://tiles.immich.cloud",
      "https://immich-tiles.yasking.org"
    )
    .replaceAll(
      "https://static.immich.cloud",
      "https://immich-static.yasking.org"
    );

  const headers = new Headers(response.headers);

  // Body 已经被修改，这些头可能失效
  headers.delete("content-length");
  headers.delete("content-encoding");
  headers.delete("etag");

  headers.set(
    "content-type",
    "application/json; charset=UTF-8"
  );

  headers.set(
    "cache-control",
    "public, max-age=3600"
  );

  return new Response(text, {
    status: response.status,
    headers,
  });
}

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request));
});

而后在触发配置中添加触发条件：

HOST 等于 immich-tiles.yasking.org
并且 URL path 等于 /v1/style/light.json 或 /v1/style/dark.json

配置后继续调整 EdgeOne 的缓存时间（针对 mvt 后缀文件）

访问测试

待部署完成后访问 Immich Map 页面，可以看到请求已走自定义域名。

瓦片地图从 EdgeOne CDN 加载，速度从 1s+ 降低到 100 毫秒级别。

访问一会儿地图后回到 EdgeOne 控制台，可以看到请求数飙升，符合预期。

修复 macOS 迁移助手会导致 OrbStack 文件损坏的问题

2026-08-19T13:18:00+08:00

先修复文件所有者变 root 的问题。

sudo chown -R "$USER" ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data

服务启动后如遇弹窗报错则继续，不要点击 Reset。

OrbStack data has been replaced with an empty file.

This is usually caused by Migration Assistant. To fix it, click "Reset" to delete your old data and start over.

这是因为迁移助手破坏了稀疏磁盘镜像的分区结构，先备份文件：

cp ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw ~/Desktop/data.img.raw.backup

执行命令（参考的这个 Issue: #2472）

命令说明：8796093022208 = 8 TB，是 OrbStack 默认虚拟磁盘大小、不会立刻占满 8 TB 磁盘，只是恢复稀疏文件的 “表观大小”、迁移时末尾的 GPT 备份区可能被截断，扩回去后 OrbStack 有时能重新识别分区。

truncate -s 8796093022208 ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw

我执行后问题得到解决，镜像、容器均恢复正常，特此记录。

香港 Day2・赞美之泉演唱会

2026-08-15T14:06:00+08:00

第二天的天气也是阴的，听着外边儿淅沥沥的雨声和车压过路面的声音，也就没有早出去的心情，中午饿了就打算出去吃点儿东西。

香港土地资源有限，楼房总是高耸林立。

路过 711 便利店，看到之前去日本喝过的 ‘酸酸’，来上一瓶。

到达午餐目的地，名为牛奶冰室。‘冰室’ 早先是喝饮品的地方，类似国内的奶茶店，后来不断的发展（什么都卖），现在有些类似快餐馆的感觉。

他家的菠萝包在大众点评上看挺推荐，很香甜，内部是浓浓的芝士，烫烫的口感不错。

另点了冻鸳鸯、牛肉炒河、嫩鸡米线。冻鸳鸯有比较明显的茶的味道，不太甜，我挺喜欢，牛肉炒河粉味道丰富细腻，比昨天的大排档炒牛河更好吃，嫩鸡米线吃着没什么味道。

这一餐价格亲民，共计 HK$156。

下雨天就适合躺着睡觉，午觉后的下午没什么事儿，就往会展中心走，本地人感觉不怎么用雨衣，北京地铁守护我的出行。

到了会展这边

赞美之泉音乐会很棒，满有氛围感和感动。

结束之后想着还是到港边走走，下着小雨也没什么人，会展中心旁有一块「香港回归祖国纪念碑 —— 江泽民」，此时电视正播放江主席的纪录片《江泽民》。

随便转转就坐地铁前往住宿的宾馆。

Day2，已经有些适应 ‘湿漉漉’ 的香港天气了。

Memos: DeepSeek 在我的轻量使用场景下 API 价格涨幅近 4 倍

2026-08-14T10:35:00+08:00

我把过去 30 天的 DeepSeek 账单让 AI 分析，整理出在我的使用场景下的成本结构，缓存命中 96.88%、缓存未命中 2.55%、输出 0.56%，圆整成 97% / 2.5% / 0.5%。拟合出来的有效价格公式：

$\text{EffectivePrice} = 0.97H + 0.025M + 0.005O$

$H$ 、 $M$ 、 $O$ 分别是缓存命中 / 缓存未命中 / 输出的每百万 token 价格。

把这 3.5 亿 token 按新价重算（按 60% 峰时占比）：旧账单 ¥29.64，新价约 ¥116，涨了近 4 倍。

这个涨价幅度的 ‘滑动变阻器’ 应该调到哪一档呢，姑且定为 ‘难梁有余，梁子不满’。

此时更推荐使用套餐，可以参考这篇 Memos：Command Code 以及 OpenCode 的订阅还不错。另外评论区有朋友提醒目前 OpenCode 的 DS V4 Flash 是免费的，我用着稳定性还不错。

Memos: 博客支持 LaTeX 数学公式渲染

2026-08-14T10:16:00+08:00

给博客加了 LaTeX 数学公式支持，方案是 KaTeX + 构建时预渲染为静态 HTML，语法为 $...$ / $$...$$，这里记录几个示例。

行内公式

正文里插入公式不用换行，比如质能方程 $E = mc^2$ ，或者二次方程的求根公式 $x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$

块级公式

独占一行、居中显示，适合放推导或者定义：

$\int_0^\infty e^{-x^2}\,dx = \frac{\sqrt{\pi}}{2}$

$\sum_{i=1}^{n} i = \frac{n(n+1)}{2}$

按需加载

没有公式的文章不会多引入样式或字体，只有页面里真的出现渲染结果时才加载对应的 CSS。

Memos: 博客添加了一个 /ping 路由

2026-08-13T17:36:00+08:00

访问：https://blog.yasking.org/ping

国内返回「Served by EdgeOne CDN and sourced from Cloudflare Page.」，海外返回「Served by Cloudflare Pages.」

借助 EdgeOne 和 Cloudflare 的 Functions 实现，解决了我不能快速知晓网站数据来自哪里的痛点。

Memos: 作为交通参与者收到的第一张罚单

2026-08-10T11:36:00+08:00

上周发现我的小电驴前后刹车拧到底也没什么减速效果，赶着周末去修理刹车，并非刹车片磨损，师傅拿螺丝刀紧了刹车线就好了，没收我钱。

回去的路上抄近道走，心想可别修车没花钱，没戴头盔被交警罚一笔。

然后拐弯骑了一百米就看到两位年轻交警向我挥手，微信扫描支付了 20 元。戴头盔是好事儿，唯一的问题就是头盔没地方放，可能需要更换一个稍大些、座椅下方能收纳头盔的电瓶车。

另外车筐里是不能放什么东西的。放过擦车座的抹布，某一天丢了。之后我就放两块擦脸巾在车筐里，倒是没丢，但我发现车筐里有个烟头，这过于危险，很难认为这个人不是故意的，看来纸巾也是不能放，电瓶车得找个有监控的地方停着。

香港 Day1・初到铜锣湾

2026-08-10T10:18:00+08:00

晚上下班儿赶往大兴机场，体验下香港快运航空的红眼航班，大兴机场凌晨也还是有不少人在候机。

飞机看着小小的，忘记了什么型号。

香港快运航空不仅只有手提行李额，据传也是知名的 ‘生鲜速运’，全程冷链运输。（貌似毛毯是收费的）

落地香港，这飞机越看越像物流速运 😂

早晨到了后有些疲惫，出关前看到个休息区，索性在这里小憩了有一会儿。

趁这个时间我连上机场的 Wi-Fi，提交了汇丰银行的银行卡申请。

早餐在 711 买了点儿吃的解决下，使用八达通卡刷卡还挺方便的，这两天在香港，八达通 + 支付宝覆盖率 95% 的支付场景。

琢磨着怎么到市区，就看到机场快线，就上车了，这不是地铁吗？票价一个人要 120 HK$ 🤷‍♂️

这次出行日期不太佳，香港怎么一直下雨的。

好在香港连廊很多，不太影响出行，中午简简单单吃个面，这个名为 ‘崩沙腩’ 的面条，肉很是不少，味道也尚可，但吃不了肥肉的人真不要点这个。

饭后仍未到酒店的入住时间，就打算到香港的基道书房逛了一圈儿，香港的出租车特别有港风。

雨伞除水器，不同地区对于湿漉漉的雨伞的处理办法差别还蛮大的，国内的办公楼见的较过的是发放雨伞塑料袋。

计划帮朋友带一本书，书店中有很多有趣的小物件。

到了酒店入住时间，赶回酒店躺平会儿，我订的酒店一晚三四百，是进门后有四个房间的那种，相当于租的一个房间 🤔

晚餐去周边一个菜市场上边的大排档吃饭，本地家人同事聚餐的不少，周五晚上人超多。

点了三个菜，菜码很大，跟东北菜有一拼。

芝麻鸡比烧鸡香一些，脆皮的芝麻蛮有特色，避风塘虾很好吃，‘避风塘风味’ 最出名的是避风塘蟹，如果喜欢吃螃蟹应该不会错过这道菜。

另外主食干炒牛河有些超出预期，有滋味的同时咸淡又恰到好处，这顿饭菜港元 HK $304，如果去大馆子我猜测没有 HK$ 500 下不来，放在东北大概 120 人民币左右，这么看香港物价不便宜。

然后想着点瓶本地的啤酒尝尝。

这个叫蓝妹的啤酒在香港很常见但并非本地啤酒，味道跟青岛啤酒比就很一般。

酒店赠送的两瓶水容量大概有 ‘5岁山’ 的量级，自己在超市购买了一瓶 1.5L 的 Bonaqua HK$18.9，又是感受当地物价的一天。

Day1 End

二〇二五年 · 林间新坟

2026-08-08T14:05:36+08:00

父亲曾带我来过祖坟，他清扫了太爷的坟头，摆上白酒和干粮，以求平安顺遂，老坟的左前方是大爷的坟，略比太爷的坟头低些，林间落叶满地，亦如今日，坟头右前方的钩机在风水先生的指挥下，在地上划出一块矩形，清理着林间散着的枯枝落叶，风水先生总是要多看几次罗盘，终于确定了方向的准正，不偏左右，钩机就下铲挖开了新坟的第一捧土。

入冬后的土地没什么水分，但也不是很干，夹杂着些许纤细被折断的树根，坑的最底层整齐码放着老式红砖，上面铺着红色的毯子，重有几十斤的大理石板侧立在红毯的四边，似有薄雾让我记不得红毯上摆放的各样物件，垫底上平整摆放的木匣在坑中的右侧，木匣有半米有余，这些都是父亲一个人在做。

爷爷下葬那天，缓缓的山坡上，二大爷（奶奶本家的大伯）开着拖拉机，载着披麻戴孝的父亲，车斗拉着棺椁、白马和花圈，突突的往山坡上爬，不时发出柴油机的轰响，爷爷的子侄们也都上了年纪，远远跟在后面连成了一条线，大家手里都各自拿着大包小裹的纸物件。

想来爷爷“头脑不再灵光”是早就有了迹象，人常说“人老腿先衰”，那些年爷爷就不再爱出门，会跟大家说他的腿没劲也用不上力，东北的冬天格外漫长，屋外冰天雪地不适合老人散步。从客厅到厨房，小老头拿着扫帚走来走去，从原先阳台餐桌边的四处走动，到机械的沿着客厅到厨房的直线行走，这是他每天最多的轨迹，家人将瓷砖地面卫生的清扫工作分派给他，这个时期的爷爷就总会走着走着，然后就忘记了要做什么。

更早些时候，他大部分的休闲时间都用来抽烟、小酌和看电视，墙壁发黄的角落、花盆里的防虫烟灰都是二老的杰作，买回来烟叶自己卷，爷爷点着一根，奶奶也一根，一根接一根，我不抽烟的原因大概是被熏染出了被动抵抗力。

后来小老头也就没法这般“快乐”，有很多事情记不得，本就不多的话语也更少了些，家人“限制”了他的香烟供给量，他们也会有些恨铁不成钢的说他“以前多聪明的脑袋，现在糊涂成这样”，我理解他们不太能接受他现在的样子，就说“唉，我爷他也是年纪大了，记忆力不好，也是没办法”，他们另外不能接受的是爷爷陆续也认不得人，从远房亲朋，再到自己的儿女… 都渐渐不认识。

我常年在外工作，一年回一两次家，爷爷虽遗忘了很多，但仍记着我，看到我时笑容满面，遮不住的开心，爷爷平日一定很挂念我。

二五年的春节见到爷爷，他已经不能自理，吃饭要戴着围巾，需要儿女帮着翻身，架着下床。爷爷走之前的半年多时间，他一定很难熬，我只听说后来没办法吞咽，只能用食管喂流食，身体消瘦，腿上的皮肤也开始溃烂，印象中的爷爷总是乐呵呵的，想到爷爷的儿女无法接受他现在的样子，其实我亦如此，我常强迫着自己不去想这些。

二五年的感恩节，这天忙完工作，看到新闻香港楼居民楼大火遇难者甚多，下班计划着参加感恩节的活动，五点钟爸爸打过来电话。

“你爷不行了” “什么？” “已经不行了，你看能不能回来” “啊我我回去，我看下”

挂断电话我愣了好一会儿，两只手在自发的操作着手机，思绪也无法维系，打开手机查看最近的航班…给妈妈打电话…高铁晚上的时间没有了…给妻子打电话…爷爷明年二月份的生日即将八十岁…姑姑在群里说大家快回来、爸没气了！…另一个群里感恩节活动在如火如荼地筹备…对！先请个假。放下手机，我愣在原地，只是仍不愿相信，爷爷真的已经不在了。

再次见他是在县城殡仪馆的告别厅，我和妻子站在屋中的角落，屋里很充满悲寂的安静，只姑姑一人哭着说着，遗体整容师是值得尊敬的，他们给死者应有的尊重和庄严，爷爷很安详的躺在那里，各种记忆的碎片涌向我，紧咬着嘴唇眼泪从眼角滑下。我暗想自己多看几眼，记住爷爷最后的样子。

我很想更多的了解这个老头，他年轻时的故事，面临的抉择与梦想，遗憾的是在他还能聊天的时候我没想过要问，也不知道要问什么，或者说只想多弄会儿手机和电脑。

那天在新坟前的空地，下山时我走在后面拾了两片落叶，因这落叶就停在那时那刻，想起爷爷的时候，能寄托住我的思念。

图一：2024年10月7日 09:22，爷爷坐在阳台晒太阳，爸爸坐在一旁的椅子上。

Memos: Command Code 以及 OpenCode 的订阅还不错

2026-08-07T20:07:00+08:00

我使用 DeepSeek API 较少，大多数时候搭配 OpenCode 交叉 Review 代码，这几个月账单都是三四十元人民币；

过阵子 DeepSeek API 要涨价，感觉找个 Plan 会更加划算，以下两个都是不错的选择：

同事推荐了 Command Code，$1 Go 套餐（算处理费实际 $1.36），现在 DeepSeek V4 Pro 也有较大折扣（已购买，感觉很适合我轻量使用）；
OpenCode 首月 5 美元 Go 套餐（月抛），单看 DeepSeek V4 Flash 的 Token 量大概是 Command Code $1 套餐的 6 倍，量大管饱；

Memos: 还真有人会看《乡村爱情》的小说

2026-08-07T20:05:00+08:00

今早在地铁上随意一瞥看到个东北小哥在看小说，屏幕上赫然出现 ‘谢广坤’、‘刘能’、‘刘英’ 几个名字硬挤进我的镜框。

我挺诧异，这电视剧还有小说版？

学生时代，没有电视机话语权的我曾 ‘被迫’ 看过电视剧版的《乡村爱情》，每集都很高能，张力和冲突拉满，村里各种糟事破事儿听着就会让人火大，至今仍难以理解大人们能从中看出什么乐子。

艺术来源于生活，但过于真实可就成了纪录片，想到没在村里久住过的人常盼望回归田园，只能默默祝福回村的人不会上演 ’乡村爱情‘。

Memos: DeepSeek 模型 API 将较大幅涨价

2026-08-06T14:37:00+08:00

以上是主流模型 API 输入、输出价格统计，不知道此次较大幅度涨价之后，梁圣是否会变为梁子。

当前 DeepSeek 价格记录：

盲猜模型 API 价格会持续上涨，5 年后回来比较看看。

Memos: 领取赛博菩萨 Cloudflare Wallet 用户名

2026-08-06T09:27:00+08:00

访问 https://cloudflare.pay，填写喜欢、未被占用的用户名，每个账户只能绑定一个名称。

大陆居民申请香港汇丰银行卡流程记录

2026-08-04T18:20:16+08:00

前置条件：

人在香港，手机连接香港的 Wi-Fi 或蜂窝网络（国内卡开数据漫游/香港流量卡）；
手机需支持 NFC 功能（读取港澳通行证）；
港澳通行证剩余有效期不少于 6 个月；
可使用 +86 国内手机号接收验证码（开短信漫游）；

附加信息：

在应用商店搜索 “HSBC HK Mobile Banking“ 下载安装汇丰银行 APP；
在国内就开通电话卡短信漫游功能，如果人已经到香港发现无法接收短信，中国移动用户最便捷的方式是在「中国移动国际漫游」公众号的 ‘我的服务’-‘在线客服’ 中找人工客服开通（提供服务密码或身份证后几位）；
地址填写在国内的居住地址，后续会往这个地址邮寄银行卡，务必准确；
我提交申请后没有立即通过，显示需要 5 日人工审核，实测周五上午申请，下午稍晚时收到审核通过通知；
申请通过后即可登录 HSBC HK App 查看账户，并使用转账、收款等账户功能；
存现金：不同的 ATM 支持的功能不同，往账户存储港元现金需要找到有 Cash Deposit 存钱妥标志的 ATM 机，不用担心存错，输入账号后会回显用户名；
线上汇款：当前交通银行汇款免手续费，汇率也不错，实测体验良好，搜索 “跨境汇款” 入口进入，页面可以看到 “跨境支付通”，收费政策可能调整，建议先小额汇款验证，以汇款页面实时显示为准。

存钱妥 ATM 机

交通银行

2026-08-06 补充：

周五申请通过，周二晚间收到邮政的 EMS 邮件邮出提醒短信；
EMS 很快，周三晚上送达；
看 EMS 上收件地址是申请时填写的中文的地址；

Memos: 终章之为 GG 卡选择一个慈善 PLAN

2026-07-30T15:30:00+08:00

在收到 GG 卡清退邮件、彻底无法发送短信之前，选择一两个喜欢的项目奉献爱心 ❤️

推荐	公益项目英文名	公益项目中文名	公益方向	短信内容	发送至	支持金额
1	Make-A-Wish UK	英国愿望成真基金会	帮助重病儿童实现愿望	`WISH金额`，如 `WISH6`	`70450`	£1–£20 任意整数金额
2	Young Lives vs Cancer	青少年抗癌援助组织	帮助患癌儿童、青少年及其家庭	`HELP`	`70030`	£3
3	Samaritans Central London	撒玛利亚会伦敦中心	自杀预防与心理危机支持	`SAM3`、`SAM5`、`SAM10`	`70470`	£3 / £5 / £10
4	BBC Children in Need	BBC 儿童援助基金	资助英国弱势儿童和青少年项目	`FIVE`、`TEN`、`TWENTY` 等	`70701`	£5 / £10 / £20 / £30 / £40
5	Cats Protection	英国猫咪保护协会	流浪猫救助、收容与领养	`THREE`、`FIVE`、`TEN`	`70030`	£3 / £5 / £10

不用加区号，直接编辑内容并发即可。

我选择了青少年抗癌（£3） + 帮助重病儿童实现愿望（£6）。

Memos: GG 卡 GG

2026-07-30T09:02:00+08:00

昨天收到 giffgaff 的 “We’re disconnecting your service” 邮件。

尝试发了邮件申请退款，但估计 £9.39 余额退不回来。在无法发送短信之前，可用余额支持公益项目。

（R.I.P：2026.4.21 - 2026-07-29）

Memos: 苹果系统在它工作的时候会工作的很好

2026-07-30T09:01:00+08:00

换苹果电脑迁移，之前我会在新电脑安装环境，古法手工进行配置，然后再手动将需要的配置、资料导出，避免旧系统很多垃圾数据被迁移助手带到新系统。

然后这次我打算让 Codex 搭配 Sol 5.6 High 模型给我写个 ‘dotfiles tool’ 工具，用来收集旧电脑的资料，再自动应用到新电脑环境中。

Codex 耗时 5 小时消耗了 1.5 倍的 Plus 周额度（期间 Tibo 按下了重置按钮），写出一个不知道是否有 BUG 的工具，我哪有时间慢慢测试啊？

然后我就想通了，软件开发环境重新折腾一遍劳心劳力，各项配置和数据也没法保证无遗漏，还是交给苹果迁移助手，于是在旧的系统上使用 Mole 先清理一遍。将低频使用的软件卸载、让 AI Agent（DeepSeek V4 Flash 模型就够用）扫两遍系统看有什么可删的，最后腾出不到 100GB 的磁盘空间。

将旧电脑的 15.3.1 系统版本升级到最新的 26.6 Tahoe，连上雷电5数据线，准备迁移。

但怎么调整重试都不再识别雷电（能确定数据线没问题，因为旧系统之前使用过这个数据线显示了雷电标识，显示预估速度也在 3137 MB/s），只好慢速同步，60 多万个文件平均速度 80 MB/s，等待了一两个小时同步完成。

迁移完成后也就不纠结了，登入新系统，一切都在，可以直接使用。

Lake Tahoe 中文名太浩湖，看起来景色很美

Photo by Drew Dau on Unsplash，原图可点击：Download 下载。

Memos: 昨天发现 caffeinate -i 能避免休眠

2026-07-29T17:21:00+08:00

偶尔我会连接手机热点让 AI 干活儿，macOS 不操作过一会儿就会进入睡眠，断掉 Wi-Fi 连接。为了避免这种情况我有几次都是手动滑动触摸板来不让电脑休眠。

无意间了解到 caffeinate -i 命令。之前居然一直手动滑触摸板 🤷‍♂️，真是被自己蠢到了。

Memos: 多子多福

2026-07-25T21:15:00+08:00

下载原图: Download

Memos: 精打细算

2026-07-24T19:00:00+08:00

下载原图: Download

Memos: 反客为主

2026-07-24T08:50:00+08:00

下载原图: Download

Memos: 形同虚设

2026-07-23T19:30:00+08:00

下载原图: Download

Memos: Grok Build 可以试试

2026-07-17T19:20:00+08:00

官网：https://x.ai/cli

登录后就能使用，免费用户也有一些额度，但是使用 /usage 命令需要升级付费？

目前看可以作为 Review 代码的一个交叉验证的补充。因为我在使用 5.6 Sol、Sonnet 5 以及 DeepSeek V4 Pro 几轮 Review 后 Grok 4.5 仍提出了 7 个有效的 Nit 建议。

终端易用性比 Gemini 好点儿但不多，勉强能跟 OpenCode 做一桌。

Memos: 谁不想用自己媳妇儿的形象做个电子 “Pet” 呢

2026-07-17T18:45:00+08:00

ChatGPT 前两天不是出了 Work 模式，今天用网页版也提示我切换 Work 模式体验。

跳转后提示我可以创建自己的专属 Pet，倒很简单，上传图片就行。

示例图：

然后就会生成动作分解的图像：

Web 端它会自动应用，图像可以下载到本地，让 Codex 基于这个图像制作，就能得到桌面版 Pet。

到设置中选定。

大功告成，‘小伴’ 鼠标悬浮效果

‘小伴’ 左右拖动效果

暗色 Zed IDE 背景

又做了个 ‘海风小伴’

晚上给她看看，预计不会打我。😄

Memos: 洗碗机太大，洗碗机太小

2026-07-17T18:08:00+08:00

前几天看 V2EX 大家讨论洗碗机，想了下出租房倒也可以买个小的用。因为一些限制因素，购买了美的的手动上水款 M10 Max(4 套)。已经使用了几天，使用频率 1-2 次每天。

有洗碗机后最满意的两点：

洗碗机洗出来的碗碟比手洗干净太多；
不再浪费时间在一日三餐产生的碗筷盘碟上，节省了很多时间；

手动上水目前还能接受，比刷碗简单的多，另外摆放会花些时间，好在越摆越熟练。

洗碗机真的能提升幸福感。

洗碗机耗材赠送了碗伴三合一，挺好用，自己在拼多多购买的亮碟海外版，使用起来香味较重，可能量较大不适合小洗碗机，也可能是本身牌子的原因，后续打算试试水卫士的 8g 洗碗块，性价比更高。

所谓 “洗碗机太大，洗碗机太小” —— 太大，是因为即使只有 4 套容量，摆在出租屋里仍然很占空间；太小，则是因为再大一些，就能把锅碗瓢盆一起装进去，真正彻底解放双手。 🤷‍♂️

从无脑缓存并发到数据库仅索引查询

2026-07-16T19:20:00+08:00

经过几个月的渐进式重构优化，V2 版接口顺利上线，接口响应时间大幅降低、也比第一版本的接口耗时更稳定。

记录一下项目之初做错了什么？

使用 PostgreSQL JSONB 数据类型存储过重的元数据，后续业务的扩展导致数据量过大，批量获取会面临查询、解析等一系列性能问题；
API 接口返回内容过多，且随着业务发展字段越加越多，单资源数据 100 KB+，批量获取传输耗时显著增长；
Go 并发是甜甜的陷阱，第一版接口在遇到性能问题后使用 Go 协程 + 二级缓存（Redis + 内存缓存）的策略进行优化，且通过接口自动构建缓存，接口的耗时产生抖动，忽高忽低；
短期内确实解决了性能问题，治标不治本，也因着二级缓存方案被作为解决性能问题的基础策略，在多个模块中使用，陆续的缓存不一致问题开始出现，定位问题变得困难。

此时接口已积重难返，无法继续优化：前有接口返回结构无法更改、后有缓存不确定性虎视眈眈。

吸取了经验教训，V2 版的接口做了以下调整：

API 默认返回基础结构，需要各样附加信息使用参数声明作为附加数据返回；
通过 Task 预先构建宽表数据源，JSON 数据拍平，非元数据内容移到业务表、资源表，接口从数据库直接走仅索引查询；

效果良好，获取基础数据时耗时大幅降低，且没有耗时抖动问题，额外的好处是可测试性大幅提升，数据库中的数据所见即所得。

Memos: 记录当下基于 AI 御三家基础订阅的编程流程

2026-07-16T16:14:00+08:00

其实目前只有两家。美国豆包现阶段不太适合参与日常编码任务，Gemini CLI 更是难用到让人怀疑它是否真的由 Google 出品。

让 Claude Code 的 Opus 4.8、Sonnet 5，Codex 的 5.6 Sol 等能力更强的模型负责评估，并设计详细方案（告知后续将由低智模型编码，务必完善细节、做好验收标准）。

交由 Cursor 的 Opus 4.6 High、Composer 2.5 等“成本较低”的模型实现。

最后再由能力更强的模型验收，并使用 OpenCode + DeepSeek V4、Kimi 2.5 或智谱 GLM-5 进行交叉验证，找出可能存在的 Blocker、Nit 项，进一步优化。（Gemini 此时亦可上桌）

这套打法，理论上就是目前 AI Coding 在兼顾质量、成本与 Token 利用率的情况下，性价比最高的方案。

Memos: 快跑！说美国豆包是过誉了

2026-07-11T23:07:00+08:00

“我是 Gemini，一个由 Google 训练的大型语言模型。”

这盲测输出，一样的，就蠢蠢的。

Memos: 使用 rtk-ai/rtk 一个多月后的统计

2026-07-10T17:28:00+08:00

10000+ 自动工具调用，节省 3770 万 Token，效果喜人。

最初是一个多月前发的 Memos：推荐安装 Codegraph 和 rtk 减少 Token 消耗后开始使用，再推荐下 Codegraph，很大程度上节省了 Agent 探索项目的时间。

Memos: 大意了！1.5x2.0 米的床

2026-07-10T17:21:00+08:00

老家房子出租出去，前几天租客跟我说次卧床垫子塌陷，翻个面用过段时间还是塌。

我就计划在闲鱼淘一个二手床垫，床是 7、8 年前买，我不记得是 1.5 还是 1.8 米宽的床，租客说是 1.5 米。

【闲鱼】https://m.tb.cn/h.RyifVXB?tk=xxxxxxx CA381 「快来捡漏【斯林百兰弹簧 床垫一张，1.5宽，1.9米长，厚度约19cm】」
点击链接直接打开

【闲鱼】https://m.tb.cn/h.REEyAE0?tk=yyyyyyy 「快来捡漏【品牌铁艺弹簧床垫弹簧，1.5米✖️1.9米金属材质，高20c】」
点击链接直接打开

【闲鱼】https://m.tb.cn/h.RC1Uyxd?tk=zzzzzzz 「快来捡漏【1.5✖️1.9床垫子20厘米厚原价2000多，搬家甩卖 9】」
点击链接直接打开

我选了几个让租客看看，二手床垫很便宜，租客倒是没什么要求，不塌就行。

我人在外地，就在网上选了一个，联系货拉拉取货并拉过去。床垫 120 元 + 货拉拉 225 元。

到了之后：

不是... 这床是 2.0 米长的？我真是被当年在建材市场购买的加长尺寸床回旋镖打到了。

最后是把床垫底部对齐，上边用毯子或其它垫子填充下。

量尺寸这种必要环节真是少不了一点儿～ 🤷‍♂️

云南系列｜Day 7 返程前在丽江的一天

2026-07-05T08:01:40+08:00

到丽江了，本次行程的最后一天。

酒店在丽江古城南门附近，大堂经理很热情的介绍了游览古城的线路。

我感觉丽江古城很精致。

来到这边的久哥米线吃过桥米线，再次吃到这种用热砂锅烫熟的米线，食材新鲜，味道鲜美。

出来走几步看到这边穿着民族服饰的阿姨在边走边跳，看着像是在排练。

来到大石桥小石桥这边的一家茶叶店，名叫普香源。

尝了老板泡的生普和滇红，香气和味道都比网上买的古树红、金骏眉好喝太多，剁手买了一饼生普，装了两袋滇红，价格不便宜但我觉着品质不错。

避坑指南：不要在古城购买随处可见的 100 元 5 饼这种茶叶，都是糊弄游客的。

晚上来到古城的 ‘广场’ 这边，丽江古城的年轻人是真多，各处都在堵人。有个酒吧一条街，氛围感挺不错，各家都在大声唱...

然后不知道走到哪条街巷，在 ‘两只猫’ 店面看到一只不太好惹的狗子，感觉骂的很难听。

丽江古城是真的挺大的，时间有限，就想着再去小吃一条街（忠义夜市）逛逛。

古城夜间的很多灯效很漂亮。

路过木府（人称丽江小紫禁城），晚间关着门。

又走了一会儿，总算从古城出来，这边有个卖果切的排了很多人。就也排队买了两份，原味的果切和辣椒酸酶粉拌青芒，不太能接受加辣椒后的奇奇怪怪的味道。

来了云南好些天，终于吃上了一口烤乳扇，填充满肠胃最后一点堆栈空间。

在便利店整了一瓶 V8，算是放肆下尝尝当地啤酒的味道，下酒菜不太对劲。

第二天一早，最后整了一份儿外卖米线，赠了几个酱。

在南门附近住宿交通很方便，从沙溪过来的客车路过这里，旁边不远处也有古城南汽车客运站，可以坐客车去机场。

到机场，结束了再丽江的匆匆游览，下次再来云南估计是落地丽江，继续一路向北到香格里拉。

丽江机场安检之后有一个卖糕点的店面，很多人来这里购买伴手礼。下图这个在我的想象中是那种软软的、中间夹着奶油咸甜口的鲜花面包。

其实吃起来像起司一样硬，避雷！，下边的云腿酥味道还不错。

上飞机后有空姐 “直播带货” 😂 又看了下是祥鹏航空。

中转先到贵阳、再到北京。

在 T2 这边吃了一顿罗小二，很新奇的铁锅烹任方式，味道还不错。

这边看到一个植物，叶子油的发亮，查了下叫 “八角金盘”，常见于庭院、绿化带在南方城市比较常见。

溜溜达达，再次启程。

云南，下次见！

Memos: Upyun CDN 下线 HTTP/3 支持

2026-07-02T14:17:00+08:00

为什么我知道这个 ‘更新’ 呢，因为偶然间打开博客发现在国内无法访问。

排查发现 DNSPod CNAME 解析到的 http3.aicdn.com. 无响应。到控制台设置中已经看不到 HTTP/3 选项，遂发工单询问 “HTTP/3 功能已经下线了吗”

得到肯定的答复：「您好，该功能已下线。」

我进一步询问：「好的，请问有发邮件、短信通知没 ?」

另外友情的提示了介绍 HTTP/3 功能的文档可以一并下线（目前看已经显示了 404）：https://help.upyun.com/knowledge-base/cdn-http3/

答复：「站内信后续会补发，收到您的建议，我们会逐步进行更新。」

然后我自己把域名解析切回正常的 CNAME，博客恢复。

好在挂几天也没啥实质性损失，不过直接下线功能特性不给用户发通也不预留切换时间，硬核下线，就挺让人诧异的 🤷‍♂️

咱就说，这是认真做事的风格嘛

云南系列｜Day 5、6 在沙溪古镇的两天

2026-06-28T17:48:53+08:00

在沙溪住了两晚，本篇二合一记录在沙溪旅程。

我们在沙溪住的民宿，下雨时站在房檐下赏雨很有趣，雨从屋檐落下，拍打在竹叶上发出噼啪的声响，很有氛围感。但缺点也很明显：

—— 房间不隔音，其它游客稍高的言语会刺破该有的宁静。

沙溪游玩，重点是早起。

这里游客真是不少。一定要赶在起不来床的年轻人、旅行团、早起的大爷大妈之前。

沙溪的历史非常悠久，可以追溯到 2400 多年前的春秋战国时期。

茶马古道上的明珠：到唐宋时期，随着南诏、大理国的兴起和滇藏茶马古道的开通，沙溪凭借其地处要冲的地理位置，迅速发展成为这条古道上重要的商贸集散地和驿站。当时，沙溪不仅是茶叶、马匹的买卖中心，更因附近盐井的开发，成为了举足轻重的 “盐都”。

2001年，沙溪寺登街被列入世界濒危建筑遗产名录。次年，剑川县政府与瑞士联邦理工学院空间与景观规划研究所签订协议，共同启动了 “沙溪复兴工程”

沙溪在国外很出圈儿，这里可以看到很多外国人。

沙溪镇比较小，几条主要的街道，逛逛就会失去新鲜感，小红书上很多人推荐到桥边。

顺着小路往河边走，河水蛮清澈。

不知是不是打开的方式不对，感觉沙溪在网上评价很高，但是实地似乎不值得玩两天，我更喜欢自然的风光，沙溪的建筑逛一圈儿后就会感觉 “千篇一律”。

继续逛了会儿，记录了商户超可爱的小猫。

戏台对面商户老抽色的狗子。

附近有个卖榴莲千层的，不要买，不好吃 🙅

顺带吐槽下沙溪真没什么好吃的店，每顿饭都很犯愁。

再再再次路过网红打卡点，除了清早外一直都有很多人在排队打卡。

平时只在公司冲一杯简单的美式，在大众点评寻到一家颇为好评的咖啡店整了一杯咖啡，味道也还算不错。

逛累了就继续回到民宿，继续泡茶喝。

以上是标准版沙溪，下面记录沙溪带给我不错体验的地方。

首先就是要逃离人群，溯溪而下，呼吸也变的畅快。

右手边是黑惠江，左手是沙溪附近的村庄。

走累了就在铁索木桥旁的树荫下歇息。

看到在农忙的大叔，他把去年的玉米叶和秸秆再维在新苗旁。

查询了下可能的作用不限于 —— 防止嫩苗暴晒、防止新苗旁边长杂草、避免下雨雨水冲刷新苗附近的泥土等。

云南这边太阳特别亮，没带墨镜这几天我都学乖了出门必戴鸭舌帽，不然眼睛不舒服。不过烈日一照，白云是真白呀！

路边还看到辣椒，问了一嘴当地阿姨说叫 ‘辣的狠’ 🤔，我猜是小米辣。

我又观察到一个现象：这边种几个辣椒苗就有一颗玉米苗，大胆猜测是玉米长出来后能帮辣椒挡下阳光，然后辣椒的辣味能帮玉米驱虫？

沙溪周五大集

第二天的一早，正好赶上这边的周五集市，饭店的服务员小哥说不用查具体的位置在哪里，九、十点钟，看到有背篓的当地大爷大妈，跟在后边就能过去～

集市很好逛、菌子、水果都不少。

我又整了一瓶鲜奶。

认不出都是什么菌。

买了一个豆荚做的挂饰，小女孩说是她做的。

都很好看。

两块多钱买了两根香蕉（实则一根，双胞胎），味道酸酸的不怎么样。

这边不管制刀具吗 🤔 就这么随意的摆在摊位上的..

一个小插曲，第一次看到这种东西，她说是野蜜，我买了一小块几十元。

还好有 AI，查询一会儿越来越觉着这个就是上了色的糖，几十块钱妥妥被骗，果断回去退货她二话不说就给退了。

回民宿放下东西，想着还有些时间，就找了一个小黄车去周边转下，一个叫白龙潭的地方，潭水很清澈。

那天天气很好，潭水映射蓝天树影，像油画一样。

水从水阀出口涌出，特别的解压。

激流行至沟槽处又徐行缓缓，舒展柔美。

这里适合发呆放空，没什么人来，但是专门为这里坐车来蛮贵的，也很可能会失望。

回去的路上，路过一个当地的博物馆，里面介绍茶马古道、马帮和当地的历史。

很漂亮的木建筑。

旁边另一个展馆的叠马。

这是青天白日旗吗 🤔

逛完展馆，在沙溪的行程也暂时到此，之后我们回到酒店取行李，坐巴士前往丽江。

云南系列｜Day 4 剑川古城记录

2026-06-20T21:28:07+08:00

早上不知道吃什么，那就再来份米线吧～习惯了独立汤包，塑料袋装汤还真是不方便。

剑川我们计划只待一小天，作为去沙溪的中转站，上午先去逛下剑川的古城。

剑川很有历史，有很多明代的房屋保存下来，上午的时候古城人很少，蓝天白云，天气很好。

这边的巷子很多，门联也很精致。

路过一个木雕店，师傅手工雕刻。我们进去选了一块 “酸枝木”（印象中师傅这么叫），做了两个小巧的十字架，这个木头是真硬，手工刻制看着特不容易。

师傅雕刻过程中，我们就在古城中逛。剑川这边的建筑很有特色，大多是清朝时期，而少部分是明末建筑。

这两个联是悲联，感怀亲人不在。

感觉喜欢并能研究建筑的人一定会很喜欢这边，每个古建筑风格都各不相同。

回到主街，看到一些在营业的店面。

竹编制品很精致，要不是太远不想携带太多东西，真想购买一些。

瓦猫是云南特有的传统民居建筑脊兽，虽冠以“猫”名，但原型实为“能食鬼的老虎”，具有镇宅辟邪、招财纳福的寓意。它多由陶土烧制，通常蹲伏于屋顶正脊或门头之上，是云南非物质文化遗产的重要代表。

剑川古镇感觉很好逛，人少、大气、安逸。

在路旁买了这边的本地牛奶喝，有牛奶味，很新鲜，真心不错，北京怎么没有 🤷‍♂️

继续往剑阳楼的方向走，突然看到诸葛亮、李冰的介绍，有些恍惚，等等！我是在云南，而非四川？

赶紧查了下，古时、云南和川蜀地区有着紧密的联系，茶马古道也是在这边。

中午在附近吃了蒸菜，价格实惠。

饭后往剑阳楼方向走，路过「赵藩陈列馆」就进去看看，赵藩名言：

能攻心则反侧自消从古知兵非好战，不审势即宽严皆误后来治蜀要深思。

陈列馆建筑木雕很精致，我格外喜欢院子里的木质桌椅。

阳光退下时，在这里品茶可太舒适了。

出了院落再走几步就是剑阳楼。

纯木质结构非常的漂亮。

可以登记后进入内部参观，走楼梯可以上楼观看，登剑阳楼，剑川一览无余。

出来后又逛了几个古宅。这边的木雕都超级精致唯美。

资料显示，剑川木雕有千年的历史，四大木雕流派之一，剑川木匠既能盖木房子又能雕花，不分木工与雕花匠。

我就又想到之前去黄山参观，卢村卢百万家里请了四个匠人，耗时 25 年盖房雕刻，展现出徽派木雕天花板。

就难免产生对比之心，如果是纯雕花、人物和故事，细腻程度，卢村匠人的水平更高一些，而如果说全能型木匠，则剑川的师傅会高出一大截。

看着精美又有档次。

还有好几个院落和博物馆没逛，讲真给剑川县城预留的时间少了，应该再住一晚再走的，这个小县城真的很舒服。

下午找酒店的工作人员提供联系方式约了去沙溪的 7 座车，等人的间歇逛了一下本地超市。

酥油、乳扇以及牛乳饼，看着都很新奇，问了一个阿姨说不能生吃，只好作罢。

这边的山药看着好像还不错，晚上到了沙溪，简单吃了些东西就在沙溪四处走走，晚上人很少，几乎没夜生活的样子。

镇里戏台夜晚的灯光，侧面挺耐看，打光水平中等偏上。

在沙溪计划住宿两晚，下篇见。

云南系列｜Day 3 周城扎染 & 抵达剑川

2026-06-20T18:32:34+08:00

清晨醒的早，在阳台上看日出。

洗漱后到洱海边可以看到水面波光粼粼，这个时候不热，估计紫外线也不少。

回来后拍了一张酒店的照片。

出去后可以到喜洲的小黄车。

今天的行程是到北边的周村体验扎染，需要叫网约车。到周城后我们选择了一家叫 “墨染坊” 的店，实测体验不错，染料是天然的植物染料，使用板蓝根 + 石灰 / 草木灰等制作。

这是他们家使用了几年的大染缸。

使用小夹子搭配木片能做出蝴蝶和花的图案。

老板会全程指导进行染色。

需要早些去，我们十点多钟到是第一位顾客，选衣服的房间可以独享慢慢试衣服，并且制作过程安静，老板也更有时间指导。

陆续顾客多起来，体验感就会下降，好在人多时我们已经制作完，衣服挂起来晒干后色彩很棒。

他家还有一些周边可供选购。

衣服晒在外边等待的间歇我们出去逛下周城，看到街边坐着聊天的老奶奶们。

还有穿着民族服饰的阿姨。

在周城的广场有古树，实际看着非常高大，马上想到一句 “大树底下好乘凉”。

中午就在古树附近的小店吃了米线。

在这边还看到每家门前都贴着对联。

如果时间比较充足，去看了看门联也会很有意思，选了几个问了豆包门联的意思，了解到不少故事。各种本地居民巷子，媳妇特别喜欢这看看、那看看。

我看着时间不早，就催促着早些取了衣服回喜洲，下午要做客车到剑川县。

如果乘坐官方运营的“小马可达”，喜洲这边上车地点在家乐购超市斜对面，上图标记的位置（不要踩时间去，小程序上显示的预估时间差异很大，感觉古城发车很快就会到喜洲了）。

坐了几个小时，到剑川县后赶快到酒店躺平了一会儿，晚餐品尝了当地的特色 ‘酸辣鱼’。

酸辣鱼的酸味来自酸木瓜，酸香、清爽、不像醋那么冲。

里边好几条鲫鱼，吃不完，根本吃不完，晚上有些凉，想了想没出去再逛。

媳妇把扎染裙子穿上喜欢的不行。

这是酒店的床，床头窗有个大 BUG，窗帘底部透光，明早将会阳光普照，我还以为媳妇儿大早上把灯打开干什么... 🤷‍♂️

Memos: 记录老田的老北京炸酱面

2026-06-15T09:00:00+08:00

之前有篇 Memos 记录「95分」好吃的‘小帅香菇面’，提到 “与之并列的是老田的老北京炸酱面，炸酱卤+辣椒卤吃到停不下来”，又吃上了

老田是地道的老北京人，拿手炸酱面，味道绝对正宗～

云南系列｜Day 2 大理洱海之行（下）

2026-06-14T21:18:24+08:00

上篇来到喜洲这边靠近洱海的酒店入住，楼下公共区可以泡茶喝。

店名 “云海望月 Stunning 独家海景美宿” 因为连住两晚，老板给升级了房型，早晨给做的热汤面吃，老板人不错，说可以在厨房自己做吃的。

我感觉找到了舒适的洱海旅行节奏，不要只在廊道骑行，最好还是住在附近，这样可以从酒店出来沿着小路走到洱海边，欣赏早晚的风光。

只要海边有路就走，没有路就上到生态廊道上走一会儿。

这样可以很安逸。廊道中有很多可以随时扫码租借的车辆。

走着走着遇到两个长椅，坐在长椅上嗮日光浴、独享洱海，视野很棒。

继续往北走，本来打算去海舌公园转转，中午到了饭时在附近搜到一家吃饭的地方（喜穰·海舌半岛观景餐厅），这家审美很在线。

点了一份野生菌过桥米线吃，到大理第一次体验到这种用热砂锅烫熟食材的烹饪方式。

味道我认为还不错，之后回酒店歇息会儿，回去的路边有个绝佳休息区。

下午计划去喜洲转转，从酒店另一侧的门出去有附近村民营运的小黄车可以 15 元到喜洲。

喜洲淡季人也很多。

喜洲古镇比较大，有不少小巷子可以转。

遇到一只十分淡定的小猫，就趴在墙上看人来人往 🐱

侧颜很俊，但被稀罕会瞬间变脸。

喜洲古镇在淡季感觉人也还是很多，之后去附近的麦田拍照，网上看五月下旬麦子收割，本以为看不到麦子，结果这里还有的。

转为动漫风格感觉很棒！

回到主街道，买了一个冰棍儿吃，记得好像是 8 元一根，味道还真不错！

逛累了就又联系拉我们的师傅来接我们回酒店，只要十元，怒省五块。

晚餐在酒店点了一份外卖解决，坐在酒店院内的长桌前开餐。

从天亮吃到黑天。

收摊～

在 Oyunfor 平台购买土耳其区 Apple 礼品卡

2026-06-08T17:12:00+08:00

6.11 最新更新：土区 ChatGPT 已涨价，价格跟美区相同。🤷‍♂️

8.4 最新更新：好消息是老用户未涨价，仍可按 499 里拉续订 Plus 会员。

前提：已准备好土区 Apple Account

不同额度的礼品卡

首次购买，先买 500 TL 试试水

点击右侧添加付款方式，弹出页面，勾选 “I am not a Turkish citizen.”

之后添加信息

继续点击右侧的 “Make a payment”

先点击第一个信用卡，然后选择海外信用卡。

点击蓝色大按钮直接支付，512.x 的 TL（含手续费）

我在这里输入正确的手机号（+86/+44 均可），接下来填写信用卡信息付款就行，成功后会跳转到订单页面。

查看邮箱，很快能收到邮件

来到手机上，先通过设置 - “媒体与购买项目” 切换为土区账号（我的主账号是美区）

访问 Apple Store，点击右上角的头像。

选择 “Redeem Gift Card or Code”

手动输入 Code 提交

搞定！

ChatGPT 美区退订，等到订阅失效后再在土区重新订阅即可。

解决无法创建 Apple Account 账号问题

2026-06-08T15:58:00+08:00

注册土区账号遇到提示 “无法新建账号”，切换网络、使用 GiffGaff 手机号均无法正常注册。

访问 https://getsupport.apple.com/solutions；
选择 “Apple Account”；
选择 “Other Apple Account Topics”；
选择 “Creating an Apple Account”；
选择在线对话，填入用户邮箱；
开始激情对话（使用 AI 协助回复）；

参考文档：注册Apple ID提示“此时无法创建你的账户”或“your account cannot be created at this time”解决方法

云南系列｜Day 1 大理洱海之行（上）

2026-06-07T14:50:21+08:00

前几天补完 2025 五月的日本关西旅行系列，今年五月云南出行又积压下来。🤷‍♂️

本次出行前查看云南的天气，基本上都是下雨，做攻略说云南天气预报要是气温都是二十四五度以上就没事儿，犹豫再三选择按计划出行。

周六晚上落地大理，天气微凉，没远走，打车去城区住宿一晚。

有点儿饿了点了外卖烧烤，看评价倒很好，味道发甜，吃不惯。

酒店供早，来云南吃的一份儿正宗米线。

这家酒店厨房看着很干净，米线味道也不错。

中午打车到达大理古城，好巧不巧周日赶上这边马拉松封路，打车出行还有些费劲，临时选了一个妆造店。

‘侣行时光‘ 和 ’租衣服的小红帽‘ 是一家，淡季不用排队，早点到能选到比较好看的衣服，衣服加妆造明码标价，没有其它费用，当天晚上十点前回来还就可以。

中午在附近品尝了云南菜，这家叫全月饭店白族私房菜的餐馆性价比挺高，双人套餐 94 元量大管饱，味道也不错。

吃完饭已是两点多，扫了一个共享电动车到一个自行车租赁店。

电助力自行车，不用出一点力，按电门能当摩托车骑，洱海西岸好看的景色都在生态廊道上，在外边租借的电瓶车进不去，只能租廊道里面的扫码共享车，价格较贵。我做攻略研究的是这个自行车刚好可以从一个口进去在廊道骑行 ~~性价比超高（bushi）~~

老板提供给我们如下的线路导航，主打一个先苦后甜，并不推荐大家尝试。

我驮着画好妆造的媳妇儿，在路况不是太好的红色线路上顶着烈日骑行。

到了廊道就好了，人少、随走随停的欣赏风景。

这个时节洱海边的树林可以徒步。

洱海的水不是那种清澈的。

看云卷云舒。

云浮山巅夕阳远，黑夜渐至。

晚上吃了火锅，还了自行车和衣服，打车去酒店，晚起晚归的大理 Day 1 在充实中结束。

Memos: 高风险的 ‘保留最新 N 个镜像’

2026-06-03T11:28:00+08:00

“保留最新 N 个镜像” 策略听着简单明了，但极易引发线上事故，它的问题不在于镜像本身，而是系统里的很多东西并不会因为时间推移而失去价值。

正式、测试环境共用镜像仓库（正式环境的镜像 1.2.0，而测试环境使用 dev-bcba1f9 这类 Hash Tag），保留最新 N 个镜像，测试环境部署几次就会把正式环境的镜像挤掉；
曾经手动构建的古董镜像，默默支撑着一些无人维护的服务，被清理掉后可能会永久丢失；
同一套代码可能作为多个业务后端独立部署，各服务升级节奏不同，即使使用标准版本号，线上仍可能长期存在大量历史版本镜像；
ECR 允许 Helm Chart 以 OCI 形式存储，它也会被生命周期策略误伤，躺在仓库镜像列表的第 N 页之后，丢失后难以感知，直到下一个人部署；

这些因素影响之下，配置 ‘保留最新 N 个镜像’ 后，集群内服务很可能在下一次扩容、迁移或重调度时突然爆炸，如果非要自动化清理，更安全的做法是基于 “最后一次拉取时间” 且 “未被任何运行中 Pod 引用”。

Memos: 推荐安装 Codegraph 和 rtk 减少 Token 消耗

2026-06-02T11:38:00+08:00

Codegraph 和 rtk，前者通过静态分析构建代码调用关系图谱，解决 AI 在大项目中反复 grep/read 文件、难以理解项目结构和影响范围的问题，后者用于优化代码搜索和 diff 上下文。

省流：搭配使用能大幅减少 ‘无意义’ Token 消耗并提升 Agents 工具的执行效率。

大连・五一三天旅程记录（2026）

2026-06-02T09:41:23+08:00

十几年前就听说大连市现代、干净，在北方城市是独一档的，五一没规划去远的地方，就临时起意去大连转转

妻子的姐姐、姐夫在大连，这次也是难得的不用自己做攻略，体验下去哪全被带着的感觉

5.2 日，天气阴有小雨 🌧️，一行人来到傅家庄海滩

支搭起帐篷，姐夫他们听说我们过去，现准备了小桌椅

燃气炉登场，牛羊烤肉搞起来

姐夫煨肉有一手，牛肉入味、软嫩

青辣椒很辣，牛肉是那种爆汁的口感，包在一起吃每口都很满足

肉还剩下一盒，实在吃不下，还有煮锅，火鸡面收尾

傅家庄这边的海很清澈，沙滩是小石头组成的，晴天时估计很美

晚上驱车赶往东港看音乐喷泉，楼体的动感灯带蛮不错，我喜欢这个蓝色色调

五一假期晚上有两场，19:40-20:00 和 20:40-21:00，平日一般都是一场

音乐登场，用相机抓拍吧，超级 ‘出片’

音乐喷泉早到可以前排（如果有风，可能会淋些水），如果到的晚不建议夹在中间，在稍后的位置视野会更广

天下起蒙蒙细雨，广场的灯光也变得梦幻

看完音乐喷泉，步行几分钟到东港威尼斯水城，这边有很多摊位买小吃

那么大的鱿鱼 15 元一串，跟北京一个广场小摊几根鱿鱼须一个价 🤷‍♂️

旁边还有烟火气的大串，很馋，都没买，因为下午烤肉吃的太撑了

行程满满的 5.2 日接近尾声，吐槽下大连的酒店，五一假期贵的离谱，在不太降低住宿体验并尽可能省钱的前提下 2 晚就要九百多

第二天一早，点了 ‘李久堂豆腐脑（五一广场店）’ 的外卖，烤豆沙饼意外的很好吃

起来的不早，从酒店出来都快午后了，在路上看到老 201 公交车（DL3000 型），1935 年出厂，近百年时间仍在运营的老电车

中午在日月昇餐馆吃了海肠捞饭和当地的焖子，味道很新颖，这家本地菜的性价比挺高

吃饱后驱车赶往星海广场附近

五一人超多，这边也很堵车，没逛广场，索性来到滨海中路的步道散步

在山上看海，崖下有个船停着不动，用长焦瞅瞅他们在干什么？原来是海钓

这边的小树林中有好多野猫

要是我有个小院子就好了，都可以拐走，一晃又到了晚上，品尝一下鲅鱼水饺，香味十足！

晚上到酒店，发现楼下附近是一个叫 ‘东关街’ 的街区，我对于新建的 ‘仿古’ 文化建筑不太感冒，既然都来了，就也去看看，比较适合打卡出片

想早些睡没能如愿，第二天启程回到北站的路上，时间还没到，又到大连港万景街这边转转

（擀！镜头落灰了）

有不少在河边露营的人，偷偷的搞起小烧烤，遥看造船厂巨轮建造，就是大连的风有些大，一直吹吹吹我

两三天的时间真的很快，走马观花的逛了不少地方，感觉大连很适合慢下来去体验

躺在河边吊床上，刚来时，看河床都还在水下，几个小时后，原本在水下的石堆都浮现出来，第一次对潮涨潮落有了更真实的体验

五月四号没买到大连回北京的票，被迫中转来沈阳站换乘

本地人说大连已经有十多年没有变化了，四处能感受到当年的辉煌，不禁感慨城市的机遇亦难寻

大连很好！期待下次旅程

日本关西系列｜Day 6 白滨之行（下篇）

2026-05-30T10:23:37+08:00

在白滨的第二天，还好晚上还住在这边，所以还有一整天的时间游玩。

早上到 Seamore 一层的面包店买了面包吃，休息区几乎没什么人

来到无边泳池泡脚，视野很好

无边池不能走过去，可以像下图这样坐着泡脚，有单独的流动温泉水槽

海风有些大，顺着无边池往里走，有个小门，如果没锁着可以到里边看看（下图），估计是 Seamore 酒店顾客休闲区

早餐后步行前往千叠敷，距离不是太远，不赶时间不用坐车

这里的石壁远看像千层面包

能走到下边看海水涛涛

有两个樱花妹就一直站在这里望着

我也坐在这里，看水无形，听水轰轰

碧蓝的海水拍打出雪白的浪花，这一刻最适合放空

从千叠敷出来继续沿着路往三段璧走，只要有岔路口就可以走到崖壁去看看海

今日徒步量超标，没在正点吃上午饭，买包和歌山当地产的地瓜干强撑一下（地瓜干很甜、很硬）

三段璧这里有一个洞窟，可以购买门票下去看，单人价格 1500 日元

图片介绍了洞窟的行程，还有这个介绍

主要就是看海水涌入拍打岩壁，四处瞧瞧就上去了

下午两三点，计划中的两个景点看完，坐公交往回走

白滨不大，主要的景点也都是集中在海边

坐车回到沙滩这边，在路边看到一个天然温泉处理间

天气方晴，休闲度假的感觉出来了

白沙滩与海

日本玩沙的小盆友，小小的很可爱

另外一个值得的去处是海鲜市场

市场有些远，需要坐明光巴士前往，市场里各种新鲜鱼儿

三文鱼很便宜

这个鱼炯炯无神的大眼睛

最后买了一些三文鱼和虾，很鲜，别的刺身怕吃不惯没尝试

回去时的最后一班公交车等了好久，要不是还有在车站等车的人，我都以为错过了

白滨很值得多留几天，远离城市喧嚣，在温泉与海边让时间流逝，不建议匆匆的打卡，第二天一早，我们乘巴士车赶往大阪，回到动物园那边取到寄存的行李箱，经关西返回北京

第一次去日本，忍不住剁手到行李箱装不下，胜利结算画面如上，后续有时间再整理分享一些其中比较夯的商品推荐给大家

去年的行程，一年后的今天终于记录完毕 🤦‍♂️，日本关西旅程系列正式完结，手动撒花 🎉

日本关西系列｜Day 5 白滨之行（上篇）

2026-05-30T10:23:26+08:00

早起，没睡懒觉。

今日的行程是坐巴士到白滨度过在大阪的最后两天旅程，昨天住宿的地方离 OCAT 汽车站比较近，在 FamilyMart 吃了两个饭团就往车站走，图中早餐花费人民币 41.11 元

做攻略的时候有人说 OCAT 很难找，但从外边儿马路走其实很容易看到，巴士票的购买可以参考我之前记录的《日本关西系列｜网上购买大阪往返白滨高速巴士》

进去能看到一个导引牌

坐电梯到二楼 OCAT 巴士站台，不用担心找不到，有指引的工作人员，自己看屏幕指引也很清晰

在 8 号门等待 10:10 分到白滨的巴士，从图中可以看到 10:10 也有到关西机场的巴士，半小时一趟，我看坐的人蛮多的。

这趟巴士中途会在和歌山这边的服务区（Kinokawa SA）停留半小时左右可以上卫生间，不过还是少喝水，服务区有日本籍鸟儿一家五口。

乘坐的 JR 巴士如下图，上车时只能看到门就上去了，下车我拍了张照片怕上完卫生间找不到车 😂

边走边下起了小雨，说是可以看看海景也没看到

相比高铁，客车能直达酒店附近，我是坐到 S-19 新汤崎

根据红薯推荐来到一旁的 KEY NOODLE 吃面 🍜

需要先使用现金在角落的机器行购买餐券

这个海鲜面条味道就还好吧，属于漂亮饭，味道一般

附近有个热度很高的酒店 Seamore，如果预算有限，推荐我这次住的「白滨温泉纪州半岛酒店」，它在一个坡上边，离 Seamore 很近，到各处也方便

日式房空间较大，窗口风景也不错

因为临近 Seamore，附带的：

可以去 Seamore 买面包吃；
可以去 Seamore 购票参观展望塔；
可以去 Seamore 的无边泳池泡脚拍照卡打看风景；

展望塔外边看看就好，票价 2400 日元，下到水下很多玻璃窗口看不太清外边

哪里都会有到此一游的游客硬核打卡

在展望塔的廊桥上能看到著名海边温泉「崎の汤」之 ‘男性临海池’，木板另一边是女池，女池有棚子遮挡可以保护隐私

这个露天温泉据说有 3000 年的历史，有三个从高到低的池子，泉水从上往下依次流入大海，本次行程规划时间有限没有体验上，下次再到白滨一定 🤷‍♂️

下午是灰蒙蒙的阴天，从酒店往海滩走，据说去过白滨的人，手机都有这张虫虫的照片

白滨沙滩的沙子很细，海是果冻海的颜色

给家属拍到了满意的游客照

阳光刺透乌云中透出 ‘达利园效应’

海边玩完路旁就有天然温泉可以泡脚，边走边泡脚真舒服

感觉到大家都很惬意

回去的路上，找了路旁一家 BBQ 烧烤店

评价很不错，但是套餐中各种 ‘鸡肉周边’，要不是就着扎啤，真的吃不下

晚饭后外边夜幕降临，要是一个人走应该会有些害怕

回到酒店有室内的天然温泉可泡，淡季人少不用排队，泡一泡巴适的很

温泉水有认证和介绍

最后，以乳酸菌干杯，来跟这美好的一天说晚安 🍻

下篇见！

日本关西系列｜白滨明光巴士购票与乘坐（MEIKO BUS）

2026-05-30T10:12:41+08:00

明光巴士日票

我这次行程只坐了两三次公交车，没有购买巴士日票，不过也记录下整理出来的攻略：

下载 “Japan Transit Planner” 应用（红色），找到区域，选择 “和歌山”

找到熊猫图标的 “MEIKO BUS SHIRANAMA ONSEN”

包天票价格如上，如果旅程需要经常坐公交，那么买日票是划算的，以下是站点图

![[routemap_tokutoku_mobile.pdf]]

资讯来源：https://ticket.jorudan.co.jp/meikobus/ja/file/routemap_tokutoku_mobile.pdf?20210408

JR 高铁站到白滨海边

路线备忘

JR 线出来就有 “明光巴士” 始发站（S-0）
Seamore 酒店所在站点在新汤崎站（S-19）
景点「千畳敷」在 S-21，「三段壁」在 S-24 位置

公交车 ‘整理券’ 说明

上巴士后会拿到一个 ‘整理券’，整理券上有数字，代表着站的编号

下车到前门，凭这个整理券交对应的车费，具体的车费在电子屏幕上

实图记录

这是明光 Bus 公交车的样式

能看到前方的显示屏价格提示

最后：搞不清整理券坐车也不用有负担，知道在哪里下车就行，把零钱给司机，可以让他选出价格，另外看车上也贴着微信支付宝的图标，理论上也可以刷码支付。

Memos: 用 npx 做了一个终端里的 About Me

2026-05-11T11:10:00+08:00

上周做了个小工具：

$ npx @donxdone/aboutme-cli

在终端打印我的个人介绍。

起因是逛到这个博客：

$ curl -N https://jt26wzz.com/aboutme

感觉这种 “终端名片” 很有意思。但我博客是纯静态页面，没有服务器。

于是想到可以把内容做成 npm CLI 包，后来便有了我的第一个 npm 包：

Github：sincerefly/aboutme-cli
Npm：@donxdone/aboutme-cli

配置步骤记录

Github 新建仓库（例如 aboutme-cli）
Npm 注册账号（如果有则无需创建）
本地 Vibe Coding
npm login ...省略测试打包验证命令... npm publish --access public 发布到 npm
发布后在 Console 可见 Npm 包 https://www.npmjs.com/package/@donxdone/aboutme-cli
配置 Github 自动发布（NPM 包的 Settings -> Publishing access -> 添加 Trusted Publisher：选择 Github publisher，填入相关信息）
本地修改代码打标签推送 Github，Github Console 发布 Release，Npm 会自动更新

感觉 npm 的发布流程特别丝滑（相较于之前配置 Golang 发布 DockerHub），Trusted Publisher 这种「平台授权 Github 仓库直接发布」的模式，不需要自己管理长期 Token，简单又安全，又学到一种新的构建发布方式～

Memos: 6月1日起 PIR 注册局提高 .org 域名批发价

2026-05-08T11:10:00+08:00

早上看到 Namesilo 发来邮件通知 org 域名即将涨价，了解到是其注册局将批发价从 $9.93/年上涨到 $11.00/年（来源），下游的 Namesilo 价格将从 $10.79 涨到 $14.99/年。

之前博客域名每年续一次，趁涨价前按 $10.79 续满 9 年，立省 37.8 刀！

GiffGaff 英国 eSIM 手机卡注册并迁移到实体卡

2026-05-08T11:00:00+08:00

2026 年 5 月 31 号之前，通过邀请链接注册开卡，你我都将获得 £10 的赠送金：http://www.giffgaff.com/orders/affiliate/kissb994_1776743498119

先说一下我的场景，有可以临时使用原生支持 eSIM 的手机，我使用这个手机申请了 GiffGaff eSIM 卡绑在这个设备上。

过了一段时间后，我希望在日常用的手机闲置卡槽插入 GiffGaff 实体卡，使我能不依赖临时手机，于是买了一张 GiffGaff 空卡（可以在京东通过 “信封 gg” 搜索，40 元左右，或其它渠道购买的 GiffGaff 空卡），将 eSIM 转移到了实体卡上，这样转移后，GiffGaff 手机号不变，充值的 10 欧也还在，以下是我的实操记录：

第一次使用 eSIM，感觉还蛮新奇的

给自己国内手机号发送个短信

触发移动告警 😂

花费 £0.3

（可选）将 eSIM 转移到空卡

如果你有跟我类似的需求，请看下面步骤，可以在网页上操作，无需再使用之前绑 eSIM 的手机

建议在完成之前，购买的空卡不要插到手机上以避免误激活

在 https://www.giffgaff.com/dashboard 首页点击 “设置” 图标，找到 SIM card

点击 Replace my SIM 展开，官方限制的不可操作时间窗口是 “This service is not available between 9.30pm and 4.30am.”

对应北京时间的可操作时间段是 11:30 到次日 04:30，可以在下午操作。

激活实体卡

在页面上输入 giffgaff 卡号，长的短的都行，确认好号码不要输错。

之后一路点击下一步，我发现 GiffGaff 在提交转移申请后会发送一封邮件 “Your number transfer has started”，但是转移完成不会发送明确的 “Finished” 邮件。

我不急着用，就等待了一天多的时间，到官网看了下，发现没有转移中的状态后，就把卡插到了手机（国行 iPhone）闲置卡槽上，信号良好，双卡注意别选错数据流量，或者干脆不接收验证码时关闭 GiffGaff SIM 卡，使用时再临时启用。

另外转移到实体卡后，原手机上绑定的 eSIM 将自动失效。

最后，注意每五个月左右发送一条短信保活，避免半年未使用被注销，建议多设置几个渠道提醒避免遗漏

Memos: 重新学习下 Git 的使用

2026-05-06T19:52:00+08:00

这些年一直没有系统学习过 Git，遇到问题就 Google、翻 Stack Overflow，然后大部分时间都在使用 GUI 进行操作，现在有 AI 更是可以无脑让它解决冲突、自动提交。

不过当下学习 Git 仍是个不错的时机，了解其设计，才能更好的协作、管理项目，推荐以下两个资料来夯实基础知识：

阅读官方的《Pro Git》, 可以下载 PDF 和 EPUB 版本阅读，中文版：progit/progit2-zh
实操训练使用 Learn Git Branching

几百页的 Pro Git 不建议通篇阅读，我快速阅读了 Pro Git 中重要章节，略过了部署等暂时用不到的内容，搭配 Learn Git Branching 查缺补漏，感觉还不错～

日本关西系列｜Day 4 奈良的小鹿乖乖

2026-04-25T20:58:44+08:00

中午起来，在附近搜索到评价还不错的面馆，味道尚可，就是这个肉有些肥腻，点的小食鸡块味道很好！

今天的行程是去奈良看小鹿

P.S. 最近 GPT 图生图功能真不错，告诉它 “请将这个图片转换为日本动漫风格”，效果比之前好很多

路上估计有点赶，到了奈良公园就看见一个小鹿，这个鹿角好像是木头做的然后刷的漆，另一只礼貌小鹿，还很乖的让摸摸

看到有对外国夫妻/情侣在味一群小鹿

准备不太充分，下地铁在路上没遇到卖鹿饼的，导致手里空空，不过好在办法总比困难多，我们带的包里有一些饼干

给小鹿们换换口味，实测它们喜欢吃！

于是靠着几块饼干，跟小鹿进行了很多互动，让它 “点头”，“配合拍照”，喂一只小鹿时突然出来一只大孩子，吓了一跳

奈良公园很大，这里的小鹿也很多

小鹿生活在这里很悠闲、人与自然的相处很美好

下午的天气是晴转多云，我们逛完要走的时候沥沥的下了一些小雨

在路边又看到一小只

小鹿好多，超治愈 ❤️‍🩹，不过还是提醒下，不能招惹带着很大鹿角的成年雄鹿

出公园的时候，有一幕特别逗，女卫生间门口站着一头母鹿，男卫生间这边站着一头公鹿，像是站岗的打工鹿，哈哈

出来路过「奈良縣政府」，中午可以进去吃午餐，有些遗憾没能到「6樓員工食堂」体验下

日本貌似很多官方机构都能花钱进去吃饭的，这真不错，坐在这边的长凳上歇息，遇见一些日本学生，它们正合照，这只小鹿也过去了

开始往回走，奈良的城市感觉也很好逛，这次留得时间倒是不多，只看了小鹿

在地铁口的罗森买了两个小雪糕吃，抹茶味浓浓的

启程回大阪

雨越下越大，我们乘车的位置能看到机械感满满的操作间

回到大阪是下午六点多，晚餐无意间搜索到一家很棒的寿司小店：から志

小店不大

这个小店感觉是店主和他的父亲一起开的，老师傅负责切，店主招呼客人

先点了一个套餐

鱼肉品质很好，肉质新鲜可口，想加些三文鱼，跟老板这样描述的，老板秒懂，哈哈

吃完逛了一下这边的超市

看到北海道产的超大山药

这边肉感觉超好，可惜没锅烹饪！

逛完我们收拾行李离开了昨天的酒店，本来定的两晚，不想继续睡不好，就又订了另一处

这个酒店总算还不错

有一种很居家、温馨的感觉，美美的睡一觉了，晚～！

Memos: 一晃 001

2026-04-23T13:00:00+08:00

（一）Voyager 1

NASA 在 2026 年 4 月 17 日关闭了 Voyager 1 的一个仪器（LECP），官方说这样能再争取“大约一年的缓冲”。

浪漫时刻：当时 Voyager 1 已经完成主要任务，准备关闭相机以节省能源，就在这个时候，Carl Sagan 提出了一个大胆又浪漫的建议 —— 在关闭相机之前，让它回头看看地球。

这个提议一开始并不被重视，但萨根坚持推动，最终 NASA 同意执行，于是人类第一次从如此遥远的地方，看到了自己。最初的图像拍摄在 1990 年，这张图片是 2020 年的修复版：

Pale Blue Dot – Revisited (2020) JPEG (617.91 KB)

图片来源：https://science.nasa.gov/resource/voyager-pale-blue-dot-download/

（二）再读鲁迅

1）最近读鲁迅先生文章，其中 “伊说...”，查询到「伊」即现代汉语「她」的意思。

“她” 字作为专门指代女性的第三人称代词，是在 20 世纪 20 年代（约1918-1920年）由中国现代著名语言学家、文学家刘半农在新文化运动期间正式发明并推广的。

古诗中 “衣带渐宽终不悔，为伊消得人憔悴”，其中的「伊」也可理解为「她」，性别可泛指，但在语境里通常指心上人。

2）在《风波》中，七斤嫂管自己的老公叫 “死尸”，这是绍兴一带民间方言中的一种粗俗戏称，真是够硬核。

类似的也还有北方的 “死老头子”、“挨千刀的”、“死鬼”。

（三）出身

未加热的凉馒头，食用者寥寥，那如果是清华大学食堂产的，人们就有兴趣寻些打包袋纷纷装一些回去。

—— 生活观察

（四）摩尔斯编码

阅读《编码：隐匿在计算机软硬件背后的语言第二版》，第一次比较认真的了解摩尔斯编码。我觉着从实用角度出发，至少可以记住 SOS 求救信号是 点点点、横横横、点点点，点短横长，中间有间隔。

（五）一晃

在超市的公共就餐区吃饭，旁边的大哥在打电话，说 “这年刚过完，一晃五一了”，我暗想确实，时间过的太快了。

（六）关于 AI “分析屏幕收集需求”

在电梯里，一个技术人员在跟几个女同事聊天关于 “借助 AI 对员工电脑进行截图分析，可以收集大家需求”，“摸鱼都会摸，主要是分析不摸鱼...”

北京・莽山国家森林公园（2026）

2026-04-18T18:51:41+08:00

好久没爬山，我又觉着我行了

北京莽山国家森林公园之前一直是未开放的状态，周五一搜索，竟然开放了，下午没事儿拎着一瓶水就跟媳妇儿往过赶，地铁先到昌平东关，打车大概 15 元到售票处，门票 30 元一位

没做攻略，选择了 1299 登山石阶，山不高，总不运动，爬起来走走停停还略有吃力

边走边看地图，因为上山晚，最终走了黄色的线路，石阶上山，然后在长廊木板栈道下山

如果再有 3 个小时，应该会慢慢走蓝色的大圈，只带了一点点水，山顶的售卖机可救了我老命

到长廊这里发现对面是另一个景区，只能走黄色路线的路线

远处眺望，带顶的长廊在莽山景区侧是不能走的

通过长廊有一个小憩点，商店窗口锁着，没一个人，躺在椅子上晒晒太阳，就准备下山

这边的下山的路很好走，是木质的，对膝盖更友好

富有生机小草，它是大戟属（Euphorbia）植物，常见叫“泽漆”，是一种常见野草，有轻微毒性

我发现下山的木栈道视野很好，而上山的路线几乎没有景色可言

如果没大雾，俯看十三陵水库视野应该很好，斜阳的余晖映在水面有磨砂的质感

下山路程大概用了 1 小时，今天的落日圆圆的

这个岔路口，左手边直行就是 1299 石阶的方向，右手边是木栈道的方向

北京莽山最大的优点就是人少，交通方便，不太好的是打车不能到第四停车场，想爬山还需要往里走一会儿，另外近期山里在修路，爬山的时候会伴随着机器的轰鸣声，少了一份安静

我这次的体验还蛮好的，下午爬山遇到不超过十个人，四舍五入独享了整座山

日本关西系列｜Day 3 天授庵、禅林寺与排水渠

2026-04-17T20:58:44+08:00

早上起来，又来到了这家名为 Fresco 的超市

吸烟有害健康，买了两条 Seven Stars 给老父亲们，他家不支持支付宝和微信，我用的现金。

在便利店的无印良品区域买了保湿洗面奶和 SCRUB 版本、以及乳液和化妆水给家属，用了几个月感觉都很不错的。

路上看到欧美旅行团

在京都的第二天，放弃了清水寺和伏见稻田大社，打算探索些相对小众地点

来到「蹴上」站，有行李寄存箱，空闲的有很多，之前记录了一篇《日本关西系列｜使用投放硬币的行李寄存箱》

一个干净人少的小路可以一路北上到「天授庵」、「南禅寺」

天授庵成人票价 500 円

可以逛院落，不能进去房间看

后院的景色，如果是秋天应该超美

池塘上的石桥，怪树与奇石、竹林光影的交错，面积不大，但能让人安静的逛好一会儿，设计的真心不错！

骗一下池中的大鱼们，根本没有吃的 😂

因为是工作日，也非黄金周，人少体验棒。

值得特别一说的是在院落里遇到两名中国 “集美”，在安静的院落里嘻嘻哈哈，大声说话，口出脏字，没有一点素质。

而遇到的其它外国游客，大家都知道在这样环境中照顾其它欣赏美景的游客，说话都低声言语。

这个房屋上的铁网，不知道是不是用来放置鸟在屋檐下筑巢用的

一抹青苔在灰蒙蒙的土地上显的格外生机盎然，空气中弥漫着两个噪音喇叭的氛围，逛完庭院也就没了在房屋下地板躺着歇息的想法，接下来去了下一个地点—— 禅林寺 (永観堂)

往北走的路上，人陆续多了起来

日本的小店，就很日系

到了禅林寺，这里的建筑和景观都更大一些

把鞋子脱在外面

建筑都是木材建造的，在里面走起来怪 ge 脚的。

五月下旬有些热了已经，坐在 “客厅”，吹着过堂风，小憩一会儿十分惬意

院落内的红叶也很美

不穿鞋走路太 ge 脚，人也相对多些，所以这里转了一圈儿我就想到下一个地点了

因为包裹还在地铁站，所以计划往回走，在南禅寺的树下，凉爽的风甚是治愈

歇息后整装待发，我们尝试走了一个新的线路，是计划之外的惊喜

沿着排水渠一路下山

几乎没什么人，有种秘境探索的感觉

本来想着要是走着走着没了路就会回去，但是发现没有阻挡，山坡上有个废弃的铁路

照片拍不出，但身处在宫崎骏漫画中的感觉

一路走到出口，这是「琵琶湖疏水記念館」

这有张力的金色小人

出来后路过一家 “DRAGON BURGER” 的汉堡店，味道尚可，确实是太饿了

之后带着行李返回大阪住宿，途中遇到车辆故障

没办法，想了想还是换个车站，被迫 City Walk，路过一个草坪，很多人在这里歇息

路上的小渠中看到一只鸟儿 🐦

晚六点赶上打工人下班儿，站台上都是忙忙碌碌的行人

这次回大阪的酒店便宜，在动物园前附近

名为 HOTEL LUCKY，可以作为实在预算有限的选择

但是房间很小、临近洗漱间的房间还有潮湿和一些异味

原本打算住两晚，只睡了一晚就赶紧找别的酒店跑路了。

晚餐去吃了关东煮

看不懂菜单，随便选了一些

味道也就还好吧，填饱肚子，晚间又逛了附近的「唐吉訶德」

印象最深的就是，买了这个红色的吹风机（能调节电压国内可用） & 一打酸酸

来日本这两天，今天算是十分的充实，大概走了两万多步。

精致的庭院、惊喜的排水渠～结束了京都的行程，返回大阪歇息，明天去看小鹿！嘿哈！

Memos: MacOS 下编译安装 Aseprite 脚本

2026-04-13T13:00:00+08:00

Aseprite 是一款像素动画制作软件，免费试用版本不能保存，购买价格 $19.99 USD

这个软件是开源的，即自己编译使用不需要花钱。

在 MacOS 下编译安装脚本：ezefranca/asesprite.sh

已验证使用 m124-08a5439a6b 最新 TAG 可用。

日本关西系列｜Day 2 京都的半日闲逛

2026-04-11T16:46:44+08:00

昨天走了能有两万步，早上不出意外的没起来。

快到中午买了一份咖喱猪排饭吃，下午计划着去京都溜达，在大阪市区有西瓜卡基本上就都随刷随走，从心斋桥到京都还蛮远的，需要先到梅田。

我选择乘坐「阪急京都线」410 円，站台没有工作人员，候车好一会儿来了一辆暗红色的车，与 Google 地图提示的时间稍有出入，还有「特急」的标志，想了下还是先上车

能刷西瓜卡，余额不足又用了些现金，列车上的乘务小哥很好，我们貌似是上的指定席车厢，每个座位需要另付 500 円

到京都后坐地铁到「五条駅」站，订的住宿（The Pocket Hotel Kyoto Karasuma Gojo）在这个地铁口附近

这家是我和家属本次日本旅行最满意的酒店，房间不大但干净，全屋净水，一楼有好多独立的洗漱间，进去关门后是干湿分离的淋浴，总是很舒心

安顿下来终于可以出去走走，日本是左侧通行，路上发现游客们也是自适应，怎么走的都有

徒步感受下这座城市，没有目的地

看到两个日本小朋友

在路边看到一个可回收饮料瓶的垃圾桶，往里面看了看，大家都挺有素质的，真的都是矿泉水、饮料瓶，没有脏脏的垃圾

走着走着就到了「鴨川」，城市中的一个小河，附近零星的游客，遇到一些骑行的人

我觉着就是一般的小河，当作是在城市中难得的闲暇歇息之地，倒也是还好

天色渐晚，肚子开叫，步行回酒店的路上搜到一家「京町家烧肉市场小路木屋町店」的烤肉店，没吃饱，后来追加了一份石锅拌饭，两人大概花了 ¥900+ 人民币

下边这个 A5 神户牛，价格 11,000 円（约 550 元人民币）肉痛，但来都来了

因为油脂大，是那种充实的口感，家属不喜油，肉没腌制没滋味，吃不习惯，于是：

又是一顿没太吃好但至少体验了的一餐

步行回酒店的路上 1.2 公里走了很久，路过一家本地的超市，感受下「新鲜果蔬」的物价

黑毛和牛看着不错（稍次于神户牛），这次没带锅，要是能自己烹饪就可以畅吃了

海产品也蛮新鲜价廉

回到酒店，领取了两套家居服

最初计划今天也是行程满满的一天，上午没早起，下午就只是在京都徒步了一会儿～

旅途就是这样，总是会变化的，好在接下来的几天充实又有趣，且看下篇。

美国Apple官网购买礼品卡订阅 ChatGPT Plus

2026-04-09T13:12:15+08:00

使用美国苹果官方售卖的礼品卡订阅 ChatGPT 是很稳妥、安全的方案（适用于没有海外手机号、有美区 Apple 账户且想要付费使用的用户）

注意：Apple 美国官网购买的礼品卡只能用于美区账号。

访问苹果美国官网：https://www.apple.com/shop/gift-cards

点击 Buy 购买

跳转的页面选择 Email、Design 随便选一个喜欢的，for 填写被赠送人和邮箱，from 填写赠送人和邮箱

点击 Add to Bag 加入到购物车

邮箱核对好，别填写错误

而后点击 Check Out

可以选择 Guest，购买人无需拥有 Apple 账户，有邮箱、填信用卡就能买。

点击 Continue as Guest，填入信用卡信息

下方的 Billing Address 地址信息可以到网上找一个美国地址和电话填入

例如美国俄勒冈州（免税州）：https://www.meiguodizhi.com/usa-address/oregon

提交后，页面可以看到 “Your order has been placed.” 信息。

来到赠送人邮箱，会先收到一个订单创建邮件，稍等会儿后会收到一个完成邮件，间隔半小时。

之后访问 Apple 美国账户邮箱（被赠送人邮箱），搜索 “gift card”，能看到一个包含兑换码的邮件

复制 Gift Card PIN，进入 iPhone “设置 - 账户 - 付款与配送”（可能会自动跳到 ”添加付款方式“ 页面，点击返回）

点击 ”Apple 账户”，再次点击 “兑换”

手动输入兑换码

之后购买 ChatGPT Plus 就很方便，iPhone 上访问 ChatGPT 应用，应用内直接直接订阅，会自动从余额中扣款

可以看到订阅生效中

P.S. 网上有人提及在支付宝内购买的礼品卡有封号风险，无法判定真假，本文使用自己的信用卡购买官方礼品卡，是更加安全的方式

北京・中关村森林公园（2026）

2026-04-01T14:11:13+08:00

北京的春天很短，要我说也就两周。周末偷个闲，找了附近的公园去记录下花儿～

日本关西系列｜Day 1 抵达临空城与大阪首日

2026-03-28T21:22:47+08:00

这是去年（2025）日本关西旅行的行程记录，拖延了许久，决定整理出来。

2025.5.17 天气晴朗 ☀️，下午两点多到达大兴机场，16:40 分准时起飞。

我和家属都是第一次出国旅行，对本次行程满怀期待，本趟航班是中联航 KN819，2025 年机票很便宜，到大阪的单程票两人也才 1150 元。

途径韩国上空白云密布。

晚上 21:00 准点到达，QR Code 已经提前准备好了，一路跟着指引标识走

关西机场建在人工岛上，因为是晚上到的，就定了在泉佐野市的酒店，歇息一晚再出发。

乘坐南海机场线，一站就能到。

在日本使用 Google 地图很方便，能显示中文，发车时间和票价都有显示。

入住的第一晚就出了些状况，这家没有人工前台，购买后提交护照等资料，临近入住日期会收到邮件，内含电子锁的密码。

房间在二楼，电梯用码打不开，等了好一会儿有其他旅客乘坐，才跟着上去，在房门口输入房门密码无法打开，打酒店的电话，酒店工作人员的一口日语根本听不来，找去哪儿网的客服，通话质量也很差时断时续，客服说打半天才能打通我电话。

熬夜又饿又困，下车路边的便利店买的 ‘酸酸 2700’，能助我决战到天亮...

客服很有耐心的教我先按 X，再按 Y... 这不至于弄错的

从晚上十点多折腾到凌晨一点，我正计划换个酒店，在邮箱中看到新发来的邮件，跟客服提供的不一致，又试了下新密码，门竟然开了，总算成功入住（P.S. 谨慎订购没有前台的酒店 🤷‍♂️）

房间不大，但蛮干净，第一个感觉新奇有趣的地方是插座，需要推一下或者旋转才能插进去。

做攻略说日本大都是三插，我还特意买了一个转换头，实地发现两孔插座是蛮多的。

闲着也是闲着，家属洗漱的时候我还测试了一下酒店 WIFI 和流量卡的网速。

第二天早上没起来，上午去便利店买了便当吃，加购 ‘酸酸 2700’ 放进背包。

日本这边都习惯喝冷水，我特意带了一个飞利浦能加热的保温杯。

收拾妥当，乘坐南海电车到大阪市区。

先到的难波附近，打算买点儿东西。路过看到一家「りくろ一おじさんの店」，人超多，没排。

面膜、龙角散、膏药、指甲钳... 买了一堆。

平价的 Lululun 面膜家属说很好用，推荐买亮蓝色的那个，后来我又在网上回购了几包。

日本的街道、车子真的好干净！

逛的累了就在附近的松屋简单吃了些

味道还不错，价格亲民，按汇率算三十左右人民币一份。

吃完出来在路边看到有欧美人开卡丁车，陆续飙过去好几辆，最后落单的这哥们被红灯卡住。

心斋桥附近小巷子杂乱的电线杆们

下午在难波和心斋桥附近转悠，采购完成直接去了包裹寄存，在小红书上很受推荐的小店

计划返程前再来取，我的箱子是中号，存放了 7 天花费 910 円。

晚上入住的青旅叫「心斋桥笼」，没买到最火的那家民宿，但这家也带来蛮多的惊喜

麻雀虽小但五脏俱全，有十多个小隔间，两个卫生间，洗漱间设施也很齐全。

有提供中文的指引单，是真的很方便。

放完行李，在附近找了家すき焼（寿喜烧），尝尝本地正宗的

日本点餐规则跟国内不一样，两个人要点一样的套餐 x2，然后必须要点喝的，其实我只想喝点热水。

吃不惯可生食鸡蛋，寿喜烧味道可能正宗但不符合我的口味，旁边有本地一家人吃着火锅唱着歌感觉挺香的。

都说去了日本上卫生间不太容易，每顿饭后都来便利店主动买点儿蔬菜汁喝～

躺着还不困，看到他家酒店顶楼有个公共浴室，我去试了试，温泉池子不大但蛮热乎，我去的时候还没人，冲洗下就去泡着，陆续进来两个欧美人，他们是真的爱清洁，打沫洗完一遍又一遍。

旅行的第一天有波折、也有极大的新鲜感，Day 1 就先记录到这里，晚安。

Memos: 查询 Apple ID 注册时间

2026-03-27T08:00:00+08:00

查询 Apple ID 的注册时间：

访问 https://privacy.apple.com/；
点击「获取你的数据副本」，勾选「Apple 账户和设备信息」；
提交导出任务后一周时间后可以回到页面下载数据；
解压缩 zip 包，Apple ID Account Information.csv 中的 “Create Date” 列即注册时间；

查到了我的美区 Apple 账号注册时间是 2018-02-28，周三下午。

P.S. 查询 Google 账号方式见《查询 Google 账号注册时间》

Memos: Ghostty 开箱即用配置

2026-03-17T13:15:00+08:00

之前使用 Ghostty 默认配置，在网上看到有人分享了一份开箱即用的配置，效果良好已经装配。

配置和安装说明

安装字体

$ brew install --cask font-maple-mono-nf-cn

将配置放置到 ~/.config/ghostty/config

# ===========================
# Ghostty 完整配置
# ===========================

# --- 外观 ---
# 主题跟随系统深色模式自动切换
# theme = light:Catppuccin Latte,dark:Catppuccin Mocha
theme = Catppuccin Mocha

# 背景透明度（0.0 ~ 1.0）
background-opacity = 0.88

# 背景模糊（配合透明度使用，毛玻璃效果）
background-blur = 20

# 背景图片（可选，放一张喜欢的图，终端瞬间好看）
# background-image = ~/Pictures/wallpaper.png
# background-image-opacity = 0.3
# background-image-fit = cover

# 标题栏集成 Tab 栏（比 hidden 多了 Tab 支持）
macos-titlebar-style = tabs

# 非活跃分屏的透明度（让你一眼看出焦点在哪）
unfocused-split-opacity = 0.9

# --- 字体 ---
# 推荐 Maple Mono NF CN（brew install --cask font-maple-mono-nf-cn）
font-family = "Maple Mono NF CN"
font-size = 14
font-thicken = true

# 连字支持
font-feature = calt
font-feature = liga

# --- 窗口行为 ---
# 永远记住窗口状态（分屏、Tab、目录）
window-save-state = always

# 新分屏继承当前目录
window-inherit-working-directory = true

# 新窗口继承字体大小
window-inherit-font-size = true

# 内边距
window-padding-x = 4
window-padding-y = 4
window-padding-balance = true

# --- Quick Terminal（下拉终端） ---
keybind = global:ctrl+grave_accent=toggle_quick_terminal
quick-terminal-screen = main
quick-terminal-position = top
quick-terminal-size = 50%
quick-terminal-autohide = true
quick-terminal-animation-duration = 0.15

# --- Shell 集成 ---
# 自动注入 shell 集成（光标样式、sudo、标题、SSH terminfo）
shell-integration-features = cursor,sudo,title,ssh-terminfo,ssh-env

# --- 滚动 ---
# 滚动缓冲区大小，单位是字节（默认 10MB，这里设为 50MB）
scrollback-limit = 50000000

# --- 光标 ---
cursor-style = block
cursor-style-blink = false

# 鼠标隐藏（打字时自动隐藏鼠标）
mouse-hide-while-typing = true

# --- 剪贴板 ---
# 选中即复制到系统剪贴板（和 iTerm2 一样）
copy-on-select = clipboard

# 复制时自动去除行尾空格
clipboard-trim-trailing-spaces = true

# --- macOS 专属 ---
# 退出时不弹确认框（如果你习惯了 Cmd+Q）
confirm-close-surface = false

# Option 键作为 Alt 使用（对 vim/emacs 用户很重要）
macos-option-as-alt = true

原文章链接：https://x.com/alin_zone/status/2033524177295274496

代码考古：用 gitcharts 挖掘 Git 仓库的演变轨迹

2026-03-16T12:29:41+08:00

运行了几个项目，效果如下

不同颜色代表不同时期的代码，可以看到项目是否频繁重构。

注意本篇非严肃性技术文章，仓库作者的项目(koaning/gitcharts)可能会随时有破坏性改动，当前的脚本也仅适用于在本地项目根目录中执行，如遇报错建议使用 AI 进行评估和校正。

安装 koaning/gitcharts

$ mkdir -p ~/Portable/gitcharts && cd ~/Portable/gitcharts

$ git clone https://github.com/koaning/gitcharts.git gitcharts-viewer

创建一个便捷脚本并添加到 PATH

$ mkdir -p ~/Portable/bin

$ cat > ~/Portable/bin/git-archaeology <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
uv run --python 3 "$HOME/Portable/gitcharts/gitcharts-viewer/git_archaeology.py" "$@"
EOF

$ chmod +x ~/Portable/bin/git-archaeology


# 加到 PATH
$ echo 'export PATH="$HOME/Portable/bin:$PATH"' >> ~/.zshrc

$ source ~/.zshrc

之后就可以使用

$ git-archaeology --repo . --samples 80 --file-extensions .md,.js,.mjs,.py,.html,.css,.rst,.go --version-source none

当然这仍然比较麻烦，运行后若要查看数据、清理仓库中的临时文件和产出

再创建一个脚本

$ cat > ~/Portable/bin/gitcharts-add <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

repo_name="${1:-$(basename "$PWD")}"
viewer_dir="$HOME/Portable/gitcharts/gitcharts-viewer"
viewer_charts="$viewer_dir/charts"

git-archaeology \
  --repo . \
  --samples 80 \
  --file-extensions .md,.js,.mjs,.py,.html,.css,.rst,.go \
  --version-source none

mkdir -p "$viewer_charts"
cp charts/.-clean.json "$viewer_charts/${repo_name}-clean.json"

if [ -f charts/.-versioned.json ]; then
  cp charts/.-versioned.json "$viewer_charts/${repo_name}-versioned.json"
fi

cd "$viewer_dir"
uv run --python 3 --with jsonschema generate_repos_list.py

cd "$OLDPWD"
rm -rf .downloads charts git-research
EOF

添加为可执行文件

chmod +x ~/Portable/bin/gitcharts-add

之后，在Git 项目根目录下运行 gitcharts-add 命令即可自动生成和清理

# 执行
$ gitcharts-add

# 或者可以执行
$ gitcharts-add my-repo

每次运行，生成的数据 JSON 被同步到了以下目录

~/Portable/gitcharts/gitcharts-viewer/charts

查看图表

cd ~/Portable/gitcharts/gitcharts-viewer

uv run --python 3 -m http.server 8100

浏览器访问：http://127.0.0.1:8100

烹饪日记：香煎罗非鱼

2026-03-15T22:00:00+08:00

食材是从淘宝网购的冷冻罗非鱼，去骨去刺 52.9/3斤，不知道性价比如何，化开后看着肉质比想象中的要好，生鱼闻着也有肉香味

切块并清洗干净，使用厨房用纸沾干上面的水分

加盐和黑胡椒煨制，一斤鱼肉大概一啤酒盖盐，黑胡椒适量增味去腥

煨制时间十分钟左右，最好不超过 15 分钟，太长时间鱼可能会被盐重新沙出水来

热锅凉油，我使用的铸铁锅，油不要太少，可以半煎半炸

裹上面粉口感和香味都更好！面粉和红薯淀粉，配比大概2比1，比例我感觉随意一些即可

将鱼裹上面粉，抖掉多余的面粉，在过面粉之前鱼如果不太干爽，仍可用厨房用纸吸附下上面的水份

然后一个个的下到平底锅煎制，可以按照钟表顺时针方向摆放，便于知道哪块是新下的，翻面的时候也能知道最早下的

全程中小火，不要频繁翻动，让其充分定形，我感觉裹上面粉的罗非鱼不太粘锅，鱼肉也比较‘硬’，不是那种‘绵绵’的肉质，轻易不会粘锅，烹饪难度较低

罗非鱼比较好熟，并且已经切成了小块，颜色看着差不多了捞出控油就行，肯定是熟的

继续烹饪 🍳

撒上一些烧烤料，香气扑鼻，罗非鱼是很适合煎制的鱼，口感不错，营养价值一般，胜在没有刺鱼肉蛋白好吸收

进行分装，分两顿吃，最后就是厨房忘记关门，煎完鱼发现客厅油烟爆炸

Memos: 新时代程序员的顶级焦虑

2026-03-13T19:30:00+08:00

Without AI, I wouldn't be able to code. 🤷‍♂️

P.S. 感谢黄鱼 6.99 RMB 月抛 Open AI Business 车拯救了我。

Memos: 博客新增图文布局和轮播图效果支持

2026-03-12T19:30:00+08:00

借助 AI Support，博客完善了图像显示，这篇 memo 用于记录可复用的图文布局。

并排 2 张图

查看代码

<div class="media-pair">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
</div>

并排 2 张图（超过 2 张自动切换）

查看代码

<div class="media-pair">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
  <img src="图片链接" alt="图 03">
  <img src="图片链接" alt="图 04">
</div>

左对齐竖图排列（可设置高度）

下面这个布局适合竖图左对齐排列展示，可以通过 media-portrait-h-220 / 240 / 280 / 360 / 480 这几个类限制显示高度，图片会在固定高度内按比例缩小完整显示，不会被截取，也不会启用左右翻页。

查看代码

<div class="media-portrait-row media-portrait-h-240">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
</div>

自适应多图网格

查看代码

<div class="media-grid cols-3 masonry-js">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
  <img src="图片链接" alt="图 03">
</div>

单图宽度控制

下面这个单图布局适合只有一张重点图的场景，可以通过 media-w-100 / 95 / 90 ... 这类类名控制宽度，按 5% 为步进自己调。

查看代码

<div class="media-single media-w-65">
  <img src="图片链接" alt="图片">
</div>

图左文右

这里是图文混排文案区域。你可以放一段简短说明、心得、步骤、引用等。

这种布局适合「一张重点图 + 一段解释」的场景，阅读节奏会更自然。

查看代码

<div class="media-split">
  <img src="图片链接" alt="图片">
  <div>
    <p>文案内容</p>
  </div>
</div>

图右文左

给容器增加 reverse 即可反转左右顺序，移动端会自动改为单列堆叠。

你后续只需要复制这一段结构，替换图片 URL 和文字内容就能复用。

查看代码

<div class="media-split reverse">
  <img src="图片链接" alt="图片">
  <div>
    <p>文案内容</p>
  </div>
</div>

图片轮播（含灯箱）

查看代码

<div class="media-carousel">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
  <img src="图片链接" alt="图 03">
</div>

画廊灯箱（media-gallery）

主图大图居中展示，下方缩略图条显示所有图片并高亮当前项，点击 < > 或缩略图切换，点击主图进入全屏灯箱。

查看代码

<div class="media-gallery">
  <img src="图片链接" alt="图 01">
  <img src="图片链接" alt="图 02">
  <img src="图片链接" alt="图 03">
</div>

顺带，支持了代码折叠显示功能。

Memos: 最适合空气炸锅烤着吃的红薯品类

2026-03-10T19:58:00+08:00

「当属小象超市的黄金榴莲蜜薯」。

自从年前买过两次 “烟薯25号”，我一度不敢轻易购买 “蜜薯”。我固执的认为它们是泡在蜂蜜罐中长大的，烤制后流着糖浆，透露着饱含碳水的邪恶微笑，吃起来心里负担极大。

直到购买了黄金榴莲蜜薯，其软糯适中、甜度又恰到好处（在我能接受的甜度上限之下），空气炸锅烤制 40+ 分钟，散发着焦糖的香味，重拾了我对红薯的热爱，我认为其是烤食红薯 T0 级的存在。

商品详情页面介绍显示其产地为：海南澄迈县。

Memos: 记录「95分」好吃的‘小帅香菇面’

2026-03-08T20:58:00+08:00

好友小帅的香菇鸡蛋肉丁面，为了追求完美，食材均来自‘地标’原产地，一年前首次吃还能吃到某个食材味道‘更突出’，半年前吃略感勾芡过重，今天的口感夯中夯，十多样食材味道完美融合，美食不可辜负，我吃了两碗！

与之并列的是老田的老北京炸酱面，炸酱卤+辣椒卤吃到停不下来，下次再吃我发上来！

妻子爷爷的‘朝鲜军功奖章’

2026-03-08T19:59:36+08:00

过年回家躺在农村的热炕上，聊起妻子的爷爷，他参加过抗美援朝战争，在九死一生中平安归来，岳母拿出来一些当年的奖章，说还有好几枚，不知道遗失到了哪里，看着七十多年的物件，感慨系之，它承载着那段沉重的历史，也似在诉说着战争残酷，务要珍惜和平。

⬆️ 朝鲜军功奖章是朝鲜政府为了表彰在战争中建立功勋的指战员而设立颁发的奖章，也是当时授予中国人民志愿军最普遍的奖章之一。

这个是第二版的证书样式（百度百科-朝鲜军功奖章）

⬇️ 和平万岁纪念章是 1953 年 10 月中国人民第三届赴朝慰问团赠送给全体志愿军指战员的纪念章，它不仅是慰问品，更是对志愿军将士为和平作出巨大牺牲的崇高敬意和表彰。

这只和平鸽大有来头，其原型是西班牙著名画家毕加索为1952年世界和平大会绘制的宣传画。

⬇️ 这枚章是 1951 年 10 月，在中国人民志愿军出国作战一周年之际，由中国人民政治协商会议全国委员会颁发给所有参加抗美援朝人员。

它通常也被称为 “政协纪念章” 或 “毛主席像章”，它是抗美援朝战争期间，由国家颁发的第一枚全国性纪念章。

⬇️ 民国时期广州著名皮具老字号 “朱芳记” 最典型的商标标识上一只展翅的鹰。

听说是抗美援朝回来国家给的奖励。

Memos: 博客切换为 Shiki 代码高亮方案

2026-03-06T23:35:00+08:00

最近将博客的 highlight.js + Pygments 的高亮方案替换为 github.com/shikijs/shiki，这里记几个我觉得有意思、最实用的效果。

Diff 效果

在行尾写注释 // [!code --] 和 // [!code ++]，无行号和有行号两种场景效果不同。

无行号 - / + 悬在行首：

func greet(name string) string {
    return "Hello, " + name
    return "Hi, " + name
}

开启行号时符号合并进行号列，颜色跟随变化：

func greet(name string) string {
    return "Hello, " + name
    return "Hi, " + name
}

Focus 聚焦效果

非焦点行淡出，突出当前关注的逻辑。

func login() {
    validate()   
    requestToken()
    saveSession()
}

语义高亮

[!code highlight] 是无语义的通用版；info / warning / error 是有语义的递进版，适合标注关键路径、潜在问题和错误。

func insertionSort(nums []int) {
    for i := 1; i < len(nums); i++ { 
        key := nums[i]
        j := i - 1
        for j >= 0 && nums[j] > key {
            nums[j+1] = nums[j]
            j--
        }
        nums[j+1] = key
    }
}

func sortAndPrint(data []int) {
    if data == nil { 
        return
    }
    insertionSort(data)
    fmt.Println(data[len(data)]) 
}

func main() {
    nums := []int{5, 3, 8, 1, 9, 2}
    sortAndPrint(nums)
}

Hover 装饰效果

鼠标悬停才高亮，适合标注 "需要关注但不需要一直突出" 的行。

func div(a, b int) int {
    result := a / b
    logValue(result) 
    return result
}

行号（Line Numbers）

使用 ```go ln，ln 关键字开启行号，适合引用具体行或展示较长代码片段。

package main

import "fmt"

func fibonacci(n int) int {
    if n <= 1 {
        return n
    }
    return fibonacci(n-1) + fibonacci(n-2)
}

func main() {
    fmt.Println(fibonacci(10))
}

范围行高亮效果

在 info 字符串里声明高亮行，不在代码内容里留注释标记，适合引用第三方代码。ln 和 {范围} 可以组合使用。

示例中的标签是：```go ln {6,8-10}

package main

import "fmt"

func main() {
    nums := []int{1, 2, 3, 4, 5}
    sum := 0
    for _, v := range nums {
        sum += v
    }
    fmt.Println(sum)
}

然而，估计我还是会用默认效果，不带行号、不带高亮，避免代码过于花里胡哨，遵循 ‘非必要则不使用’ 的原则。

Memos: 博客新增划线、重点及荧光笔效果支持

2026-03-06T23:34:00+08:00

这是普通文字，这是划线重点。这是蓝色划线重点，这是紫色划线重点。

<span class="u-line">这是划线重点</span>
<span class="u-line u-line-blue">蓝色划线重点</span>
<span class="u-line u-line-violet">紫色划线重点</span>

这是黄色高亮，这是绿色高亮，这是粉色高亮。

<span class="hl hl-yellow">黄色高亮</span>
<span class="hl hl-green">绿色高亮</span>
<span class="hl hl-pink">粉色高亮</span>
<span class="hl hl-blue">蓝色高亮</span>
<span class="hl hl-lavender">薰衣草高亮</span>
<span class="hl hl-peach">蜜桃高亮</span>
<span class="hl hl-mint">薄荷高亮</span>
<span class="hl hl-coral">珊瑚高亮</span>
<span class="hl hl-lemon">柠檬高亮</span>

这是记号笔风格高亮，绿色记号笔。

<span class="hl hl-marker hl-yellow">Marker Yellow</span>
<span class="hl hl-marker hl-green">Marker Green</span>
<span class="hl hl-marker hl-pink">Marker Pink</span>
<span class="hl hl-marker hl-lavender">Marker Lavender</span>

记录博客字体分包与字体子集化

2026-03-05T14:16:48+08:00

本博客中文字体采用了一段时间的字体分包方案，又尝试调整为按需字体子集化的方案，整理记录如下。

字体分包

博客使用 Oppo Sans 4.0 字体：https://www.coloros.com/article/A00000074/

使用 cn-font-split 工具分包

$ pnpx cn-font-split --input "OPPO Sans 4.0.ttf" --outDir dist-font

生成内容如下

其中

index.html 是预览调试用的 Demo 网页
index.proto 是 Protocol Buffers 接口定义文件
reporter.bin 记录字体拆分的详细信息
result.css 是引入的拆分字体的入口定义样式文件

使用的话，将拆分后的众多 .woff2 字体文件放到 OPPOSans4（自定义）目录，添加到博客静态目录中，编辑 result.css 文件，注意批量编辑 URL 中的路径。

@font-face{font-family:"OPPO Sans 4.0";src:local("OPPO Sans 4.0"),url("./fonts/OPPOSans4/b8d45a4b1842853318f4cdd5ba6ef8a4.woff2") format("woff2");font-style:normal;font-display:swap;

例如我的字体放在 css 当前目录的 fonts/OPPOSans4 下，路径就是 ./fonts/OPPOSans4/b8d45a4b1842853318f4cdd5ba6ef8a4.woff2

博客加载过程中，会按需加载，以 OPPO Sans 字体为例，默认命令参数下拆分为 400+ 个字体文件，每篇文章动态加载了 10-30 个字体文件，比较零散。

按需字体子集化

这是另一个思路，把博客使用到文字汇总，将字体精简，精简后的字体文件只包含用到的字体，也能大幅减少字体文件的体积。

brew install fonttools

收集

find content -name "*.md" -exec cat {} \; > all_text.txt

过滤

sed -e 's/```.*//g' \
-e 's/`[^`]*`//g' \
-e 's/!\[[^]]*\](\([^)]*\))//g' \
-e 's/\[[^]]*\](\([^)]*\))/\1/g' \
all_text.txt > clean_text.txt

生成

pyftsubset "OPPO Sans 4.0.ttf" \
--text-file=clean_text.txt \
--output-file=OppoSans-Blog.woff2 \
--flavor=woff2 \
--layout-features='*' \
--no-hinting \
--desubroutinize

使用

@font-face {
    font-family: 'OPPO Sans 4.0';
    src: url('fonts/OppoSans-Blog.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

:root {
    --font-sans: 'OPPO Sans 4.0', 'Source Sans Pro', 'Helvetica Neue', Arial, sans-serif;
    --font-mono: 'JetBrains Mono', 'Roboto Mono', Consolas, Monaco, 'Courier New', monospace;
    --font-ui: var(--font-sans);
}

就只需要加载一个精简后字体文件。

字体子集化方案较麻烦的是需要定期执行脚本生成字体，好在未匹配到的字体会自动降级为系统字体，偶尔两个中文降级到系统字体显示并非不可接受。

P.S. 经过几次调整，OPPO Sans 中文字体 + JetBrains Mono 代码显示效果是我目前最喜欢的搭配！

Memos: 邻座吃饭的一家三口

2026-03-01T23:34:00+08:00

吃饭时邻座一对夫妻和孩子对话，对话内容让我印象较深，如下：

对话一

（夫妻俩吃完了面条，女孩买了奶茶回来）

女孩妈：你排那么长时间，怎么不给我俩带一杯

女孩：（无声）

对话二

女孩妈：那边炸鸡排看着挺好吃

女孩爸：… 滚，不给你俩买

对话三

（女孩爸在跟女儿侃侃而谈，女孩妈起身走开）

女孩爸：你干什么去啊

女孩妈：用不着你管

女孩爸：快回来，坐在这块

对话四

（女孩爸继续跟女儿侃侃而谈）

女孩爸：… 就是这点好，你他妈就是个傻逼，也能 XXX…

人在囧途之哈囧

2026-03-01T23:12:58+08:00

春节回家返京的车票提交候补一直未能成功兑现，跟去年一样，我和媳妇提前一天到车站周边等候补，尝试在临近发车时捡漏。

误信媒体巴士宣传

看到朋友转发的媒体文章《龙江巴士开通哈尔滨至北京定制班车》，哈尔滨西站发车、正规车辆、哈尔滨日报报道宣传，心想着龙江巴士可真贴心！

初八上班，初六中午我就赶到哈尔滨西站，一边候补着高铁和火车，想着如果没候补到，就购买下午 16:00 的 “五人座定制车型”，对自己狠点，18 小时铁腚回北京。

在手机下单后，我正打算去二楼候车，一个私人手机电话打过来，跟我确认是不是订购了大巴车票，说坐车等他一会儿联系，我说不是在车站里坐车吗？“不是，在车站附近”，又得知并非 5 座定制，而是 50 座的大巴。信息出现严重偏差且当天下雪，就跟他说我不坐了。

问哈西客运站的工作人员，他表示特意查询了下站内，没有到北京的巴士，最近几天得有上百人跟他问这个事情，他不清楚怎么回事，表示可能是龙江巴士平台录入错误。

赶快想把票退了，别过了时间，看到平台上退款会收一百多元手续费，打龙江巴士的客服电话打不通，客服联系不上，遂拨打 12345 反馈问题，诉求是全额退票。

大概两个小时后，龙江客服联系我并在后台操作退了票。这事儿搞的，媒体的价值，建立在事实的准确上，哈尔滨日报显然有较大的提升空间，另外第一次拨打黑龙江的 12345 反馈问题，快速有效的解决了我的问题，服务很值得点赞！

18 小时的无座你怕了吗

大巴车方案作废后，赶忙使用 12306 ByPass 软件提交了一堆候补，又实时抢票，心说初六可一定要走上，别管什么车票，初七回去能休息下，于是跟媳妇在哈尔滨西站安检口（外）就一直刷，去年就这样操作，先上车后补的票。

刷了许久，饿了点了份麻辣烫吃，还真抢到两张票，绿皮 K4044，18 小时 15 分钟的无座，有些难顶，“硬座我都不敢，更何况无座...”

考虑再三，我没退票，哈尔滨东站发车，那就去附近住下，躺在床上，电脑充上电，闲着没事儿又想抢下看有没有更好的车次，同时下单买了折叠椅做最坏的打算。

12306 ByPass 在忙着，我也没闲着，用 12306 刷中转，冥冥中我感觉有戏，跟媳妇商量了下，K4044 还是先退了吧，避免行程冲突候补失败，还是有机会抢到更好票的（也是飘了）。

退了票，努力了半天，还真让我刷到了 “更好” 的车次，一看 22:42 发车，不到一个小时，赶忙拉上媳妇从哈尔滨东站往哈尔滨站赶。

上了地铁腾出时间仔细一看，时间不对啊，不是一会儿发车，明晚的 22:42 发车，要等一天不说还要请假一天（请假困难）

脑袋冷静下来，像哈尔滨的乍暖还寒。咋整，继续在哈尔滨站安检门外刷票吧...

挺好，我媳妇没埋冤我看错时间，跟我一起刷中转，我俩笑着打趣说：“咱们这是图啥呢，在旅馆躺床上刷多好”，四处张望下，也还有一些人在安检外，同是天涯没票人。

在我们坚强的努力和媳妇的运气加持下，真抢到一个性价比不错的长春中转方案，初七晚上哈尔滨硬座凌晨一点多到长春，两个小时后高铁无座到朝阳站，高铁无座比 K4044 的 18 小时无座还是好很多，也不想挣扎了，至少有能接受的保底方案。

媳妇儿说回住宿的地方吧，我总担心万一有票，今晚就能走上多好，或者提前 20 分钟候补到，那在东站的酒店也赶不上哈站的车呀，就这样硬挺，23 点、24 点、01 点，我俩靠（东北话）走了所有从哈站发的车和安检门外的无票人。

打车回旅店，这个出租车晃晃悠悠的，旅店老板看到我俩说以为我们不回来住，房间让给别人住了，还没等我说话，他稍微考虑了下就又给我们安排了一间稍好一丢丢的屋子。

最终又回到东站的旅馆，看了下 12306 上显示 01 点到 05 点进行系统维护，就算在哈站挣扎也没有机会，回来的时间刚好。

总之、还是先吃饭

一觉过后，又躺了一上午，一是折腾的很累，二是想着上了火车就没得躺。

中午饿了在「莱福双城杀猪菜(红旗总店)」吃了东北菜，人爆满，溜肉段非常好吃！干煸豆角还好，水煮肉片中规中矩比较一般，分量都很大。

努力吃掉 2/3，花费用 99 元。

旅行折叠椅救了我的老腰

初七晚 23 点踏上途经长春的 K322 列车。

熟悉的绿皮车，大家都红着眼硬坐着，好在我就两个半小时，下了车在长春站大口喝水。

上了高铁后我在上车门对侧坐下，本来跟媳妇计划两人换着坐折叠椅，她正在那摆弄皮箱寻找舒服的坐姿。

列车员过来说：“有一个 XX 号的二等座位空着，看你们谁去做”，旁边的一个小伙没表示要去，我就跟媳妇说让她去，那个二等座位到朝阳站都没人来，我媳妇这运气真是额度充足。

我就瘫在折叠椅上，该说不说，折叠椅真是无座神器，比小马扎强一万倍，傍边高铁的暖风吹的舒服，就是每次到站开门，后腰凉飕飕的。

总之还是顺利回到了北京，困的不行，在附近的如家订了 4 小时 100 元的钟点房洗漱，下年春节真就在北京和媳妇两个人过了（手动摊手）

哈尔滨・乡村的冬季

2026-02-18T20:33:00+08:00

想触摸到粗盐粒般的白雪，看到成片的白色，唯有在东北的相间，干燥、寒冷又宁静，看不到几个人，唯有山野。

《雪地的松树林》

《白平衡》

《云、村庄与雪》

《白雪覆盖的苞米地》

《小村庄1》

《小村庄2》

《铁塔》

《日落》

《雪地车辙》

《家人》

《猎户座》

查看香烟生产日期

2026-02-17T11:38:00+08:00

过年回家前买了几条中南海流水音，感觉包装有些旧，自己不抽烟，对烟草知之甚少，查了下怎么看生产日期，发现每条香烟上都有编码（有时候不清晰，需要仔细找找）

编码有两排：

第一排的 60125 代表出场日期，6 代表年份的结尾数字，即这盒香烟是 2026 年生产（不排除是2016 年，但商店里几乎不会有十年的香烟存货，有理由认为是 2026 产），0125 表示一月二十五号。

第二排的 BJYC 表示 “北京烟草”，表示哪个地区销售的。

商店老板拿给我的这盒是最近日期的

下边两盒都是 2025-01-07 日的

经验总结：

香烟在北方一般来说，一两年内味道差别不会特别大，但是过度干燥的环境会导致口感辛辣刺喉；
购买香烟跟老板要最近时间段生产的，学会看编码能避免老板新旧掺着卖；

哈尔滨・东北虎林园

2026-02-16T19:54:00+08:00

虎林园是全球最大的东北虎人工繁育基地，里面的东北虎超多，颜值能打，大饱眼福，唯一的缺憾是人工繁育的东北虎缺少了百兽之王的霸气，缺少压迫感，不过话说回来，野生的东北虎也不是一般人能遇到的。

《东北虎》

《夫妻俩》——左侧的东北虎体型巨大，武松当年打的老虎八成不是这种

《超爱卫生的“金渐层”》

《小jio像毛绒玩具的埋汰虎》

《跟车的年轻小虎》

《一家人的午后时光》

《自助餐车》

《冬日暖阳》

《在光中，在阴影中》

《镜像》

《可以吃的“豆沙千层面包”》

《乌鸦哥的“残羹剩饭”》

《投喂》

Memos: 来自日本的 ndjp 提供免费的三级子域名

2026-02-06T18:11:00+08:00

网站：https://ndjp.net/

注册流程非常丝滑，一个账号下可以添加多个三级域名：

{your-customize}.ndjp.net
{your-customize-2}.ndjp.net
{your-customize-3}.ndjp.net
...

在子域名下，可以管理四级域名解析 A、CNAME 等 DNS 记录

blog.{your-customize}.ndjp.net
index.{your-customize}.ndjp.net
tools.{your-customize}.ndjp.net
...

三位的子域还有很多，我注册了个 ddx.ndjp.net，适合临时的学习、测试使用，风险提示：严肃场景下仍建议自己注册付费域名。

Memos: 刚听说 autojump, 真的好用

2026-02-06T04:19:00+08:00

这个工具出现在 18 年前，wting/autojump，我火星了刚听说。

安装之后，使用终端 cd 访问过的路径都会被记录，之后使用 j + [模糊字符] 就能快速跳转：

$ cd ~/Documents/BucketHub/dd-bimgs-bucket/photos

# 之后使用 j 命令就可以跳转过去
$ j pho

如果有多个 photos 目录：

/Users/joecovert/Documents/BucketHub/dd-bimgs-bucket/photos
/Users/joecovert/Downloads/photos
...

可以使用 j Down pho 跳转。

另外，jc 可以限制在当前目录下匹配跳转，jo 是打开文件夹，对我来说是刚需。

Memos: 体验 OpenCode + Superpowers + GPT 5.2 开发需求

2026-02-05T09:34:00+08:00

最近使用 OpenCode + Superpowers Skills + GPT 5.2 开发了一个中等复杂度的需求，相比之前使用 Cursor 依赖 Sonnet 4.5 Thinking 模型硬聊硬写，效率和代码质量明显提升！

记录下需求开发流程：

先使用 Cursor 协助构想需求的目标，心中对需求的实现有个预期；
整理需求的描述（关注重点信息，而非实现的细枝末节）；
使用 OpenCode Plan 模式设计实现方案；
切换 OpenCode Build 模式按照 Plan 计划严格实施；
最终人工初审 Review 代码 + Cursor Review 代码；
提测 & 联调；

第一、二步应该多花些时间，自己要清楚需求的目标和边界，第二步描述的信息应准确，但无需关注过多细节（表字段、接口字段等），需求清晰则字段必然是清晰的；Plan 模式不会修改本地文件，这个模式下借助 Superpowers 的规划能力，交互式确认问题，答复几轮后，Plan 会主动 “完结” 事项，提供详实的设计文档，使用者最终确认没问题后，即可切换 Build 模式开始实现

Do not redesign.
Do not change the plan.
Only implement according to the plan above.

输入以上描述，告知模型严格按照 Plan 实现代码，代码质量相当高，之前使用 Cursor 开发需求，总是需要反复对话纠正它的错误逻辑和代码风格，特消耗精力！

同需求重复实现的一些对照测试（依据最终产出代码的主观评分）：

使用 Cursor 依赖模型 Thinking 模式（旧有使用方式）：70 分
使用 Cursor Cli 搭配 Superpowers + GPT 5.2：85 分
使用 OpenCode 搭配 Superpowers + GPT 5.2：92 分
使用 OpenCode 搭配 Superpowers + GLM-4.7：58 分

我的结论

Cursor 搭配 Skills 有较大提升，但 OpenCode 能最大程度发挥 Superpowers 的能力，买了智谱的套餐，只能说 GLM-4.7 还得 “再炼”，实际开发依然推荐 Sonnet 4.5 / Opus 4.5 / GPT-5.2。

同样的需求描述，OpenCode + Superpowers Skills + 优质模型可以产出更好的方案和代码，三者相辅相成。

我理解，并非 Cursor 和 Antigravity 本身能力不足，而是它们对于 Skills 的使用侧重于参考和协助，而 OpenCode 对 Skills 的约束更强，更容易形成稳定、高质量的输出。

补充：我没有条件测试 Claude Code，所以无法做比较，另外同事测试了 Antigravity 搭配 Superpowers，产出的效果跟 Cursor 搭配 Superpowers 效果相似。

Memos: 杰我睿爆雷

2026-01-27T14:18:59+08:00

杰我睿是水贝一家黄金回收交易商家，通过他们的微信小程序可以充值（支付宝、微信、银行卡转账到个人账户）、然后在小程序上可以购买金条、板料，也可以把自己的首饰邮寄给他们，余额也可提现，支持 “做空做多” 等玩法。

近日爆雷。
有传言称其做空白银导致巨额亏损，也有人说人未跑路但资金已出海。当前情况是：大量用户账户中的余额、板料沦为数字，提现不打款，提料不发货。

爆雷前两天，他们仍在大力宣传 “免工费”，诱导用户邮寄金银。规则要求签收人填写其自身姓名，目前给出的说法是：该行为视为“赠予”杰我睿，分毛不返。

随后提出所谓“解决方案”：

可在小程序内登记并签署协议，可能返还 1–2 折本金，也可能经其律师测算后被认定倒欠平台资金；
不登记，基本没有任何说法。

看小红书上的受害者很多，被套金额少则千百八，多至几百万。有省吃俭用的攒金一夜返贫的大学生，有投资亏损不敢告诉家人的宝妈，也有借嫂子首饰卖金给母亲看病邮寄过去就被骗的不幸儿女，真的很惨烈。

小红书等平台上已有大量受害者发声，被套金额从几千元到数百万元不等。

有省吃俭用攒金的大学生，一夜返贫；
有投资亏损不敢告诉家人的宝妈；
有失业人员、抑郁症患者；
有借来嫂子首饰、卖金为母亲治病，却因邮寄而被骗的不幸子女。

场面非常惨烈。

这次爆雷与传统 P2P 并不完全相同。
它不只是利用人的贪婪，而是将自己包装成“良心、本分、懂行的黄金商家”，通过日常化运营建立信任，让用户产生粘性并自发宣传，逐步吸纳了买金小白、稳健储蓄者、投机交易者等不同人群，最终统一收割。

风险信号一直都在，但用户信任他们高于反诈风控，前一段时间小红书的风向还是有人吐槽警察把她的卡冻结不能充值，解锁后继续充值被锁，再解、再充！

每个人都会认为自己不会被骗，是别人不懂，对个人商家信用无条件的信任，最终成为收割自己的镰刀。

投资，风险永远是第一考虑因素：

不要碰私有盘，你图它克价便宜、免工费，它图你的本金。
贵重金属尽量当面交易，一手交钱一手交货，买卖通过正规渠道。
无监管平台不要充值，钱进去后只是显示数字，提出来的钱干不干净也都不好说。
凡是 “看起来不像金融行为的金融行为”，都要加倍警惕。
很多时候它不是骗你不懂，而是骗你懂，你以为懂他的盈利模式，懂他的运作方式。

当前经济环境下，捂紧口袋，不要盲目投资。

（本来截了一些图，想来还是不放了，人和人的悲喜也不相通，反倒像看他们的乐子，本文主要目的是为提醒读者在商家 “私有平台” 有存金、存银、存钱，尽快取出，规避风险）

GoReleaser 自动发布 Go 镜像到 DockerHub & GitHub Release

2026-01-23T11:40:22+08:00

差不多两年前学习记录过《使用 Github Action 自动构建 Release 版本》，也研究过《使用 Docker 构建多架构镜像》，手动推镜像到 DockerHub，其实一直还差最后一公里 —— 提交代码到 Github 自动构建 Release 二进制成品，并构建镜像推送到 DockerHub 仓库。

而这就是 Goreleaser 所擅长的，本文记录了相关配置和使用方式。

本地安装 Goreleaser

brew install goreleaser

Go Releaser 配置

在项目根目录执行初始化，生成 .goreleaser.yaml 配置文件

goreleaser init

按需修改，我的示例配置如下

version: 2

project_name: passkey-demo

before:
  hooks:
    - go mod tidy

builds:
  - id: server
    main: .
    binary: passkey-demo
    env:
      - CGO_ENABLED=0
    goos:
      - linux
      - darwin
    goarch:
      - amd64
      - arm64
    ldflags:
      - -s -w
      - -X main.version={{ .Version }}
      - -X main.commit={{ .Commit }}

archives:
  - id: default
    formats: [tar.gz]
    name_template: >-
      {{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}

checksum:
  name_template: checksums.txt

changelog:
  use: github
  sort: asc
  filters:
    exclude:
      - "^docs:"
      - "^test:"
      - "^chore:"

release:
  draft: true
  prerelease: auto
  footer: |
    ---
    Released by GoReleaser.

dockers_v2:
  - id: server
    ids:
      - server
    dockerfile: Dockerfile
    platforms:
      - linux/amd64
      - linux/arm64
    images:
      - "{{ .Env.DOCKERHUB_USERNAME }}/passkey-demo"
    tags:
      - "{{ .Version }}"
      - latest

注意需要在 GitHub Actions secrets 中配置 DOCKERHUB_USERNAME（以及后文的 DOCKERHUB_TOKEN），YAML 中通过 {{ .Env.DOCKERHUB_USERNAME }} 读取

Github Action 配置

创建/修改 .github/workflows/release.yml 文件，内容如下：

name: Release

on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - uses: actions/setup-go@v6
        with:
          go-version: '1.25'
          check-latest: true

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v6
        with:
          version: latest
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }}

以上配置的 secrets.GITHUB_TOKEN 无需手动配置，Docker 的两个环境变量需要配置。

获取 Docker User Access Token

点击右上角头像，点击 “Account Settings” - “Settings” 下的 “Personal access tokens”，创建一个 “Read & Write” 权限的 Token

生成的 Token 只展示一次，复制下来使用，即 secrets.DOCKERHUB_TOKEN

在 Github 上配置 Secrets

点击 Github 仓库的 “Settings”，侧边栏找到 “Secrets and variables”，我这里添加的是 Repository secrets 类型

Dockerfile 配置参考

放到项目根目录

FROM alpine:3.23

RUN apk add --no-cache ca-certificates

WORKDIR /app

# 使用构建参数获取目标平台（GoReleaser dockers_v2）
ARG TARGETPLATFORM

# GoReleaser 将二进制文件放在 <os>/<arch>/ 目录下，即 TARGETPLATFORM
COPY ${TARGETPLATFORM}/passkey-demo /app/passkey-demo

EXPOSE 8080

ENTRYPOINT ["/app/passkey-demo"]

本地测试构建

注意替换 DOCKERHUB_USERNAME 为你的用户名

DOCKERHUB_USERNAME=your-username goreleaser release --snapshot --clean

查看构建的镜像

docker images | grep passkey-demo

已构建出镜像

如果想进一步运行测试镜像，可以运行：

docker run --rm -p 8080:8080 kissbug8720/passkey-demo:latest

推送标签触发构建

git tag v0.0.12

git push origin v0.0.12

在仓库的 Action 可以看到构建任务。

构建完成后，在 Github 仓库的 releases 可以看到一个 Draft 类型的发布，点击编辑，可修改描述，二进制成品也可以编辑，发布后即对外部可见。

Github Release

Docker Hub 镜像

访问：https://hub.docker.com/r/kissbug8720/passkey-demo/tags

可以看到 0.0.12 标签后 latest 标签的镜像。

最后

从「手动编译难以维护的脚本」到「封装良好的现代化发布方案」，Golang 项目非常推荐使用 Goreleaser 进行发布。

东东's Blog

Memos: 十一约教练学了几天车

轻徒步・北京・延寿寺后山（2026）

学习 Etcd 笔记：启动与基础命令

键值的读写

查询数据统计信息

监听指键值的变化

Revision 修订概念

从历史版本开始监听

消费者知识小课堂（一）为消费者免费提供餐具，是餐厅应当履行的义务

2026-10-04 补充

北京・中秋假期的尾巴（2026）

高鲁棒性 API 设计之 Idempotency Key：并发请求与执行一致性

原子地 “抢占” 执行权

但事情还没有结束

并发请求应该返回什么？

缓存键一定要设置过期时间

Redis 原子，不等于业务原子

Memos: 风云不语，只是一个劲儿的赠送重置卡

Memos: 看着一点也危险

Memos: AI 默默的从 ~/.zsh_history 翻到 token 更新了生产环境

非京籍个体户缴纳社保(补充)：Web 端员工工资薪金个税预扣预缴

2026 北京社保下限上调｜个体户每月最低缴费 2707.44 元

Memos: 客户端藏不住接口参数和密钥

高鲁棒性 API 设计之 Idempotency Key 幂等键

幂等键的推荐值

幂等记录的作用范围和时效性

遇到 Idempotency Key 重复后的返回内容

另外的要点

Memos: 终于、用上了 Google AI Pro 套餐

Memos: 推荐试试 oh-my-pi Agent

Memos: 新计费模式下的 Cursor Team $40 已无开通必要

Redis 集群模式下使用 MGET 触发 CROSSSLOT Keys

烹饪日记：干煸蚕蛹

体验 Age + SOPS 的轻量化配置文件加密方案

安装 age & SOPS

使用 age 加解密文件

SOPS：Secrets OPerationS

SOPS 轮换密钥对

配置文件字段的加密算法

其它 sops 特性和使用方法

使用 EdgeOne CDN 加速 Immich 地图加载速度

配置 CDN

访问 Immich 地图配置页面

配置 EdgeOne Functions

访问测试

修复 macOS 迁移助手会导致 OrbStack 文件损坏的问题

香港 Day2・赞美之泉演唱会

Memos: DeepSeek 在我的轻量使用场景下 API 价格涨幅近 4 倍

Memos: 博客支持 LaTeX 数学公式渲染

Memos: 博客添加了一个 /ping 路由

Memos: 作为交通参与者收到的第一张罚单

香港 Day1・初到铜锣湾

二〇二五年 · 林间新坟

Memos: Command Code 以及 OpenCode 的订阅还不错

Memos: 还真有人会看《乡村爱情》的小说

Memos: DeepSeek 模型 API 将较大幅涨价

Memos: 领取赛博菩萨 Cloudflare Wallet 用户名

大陆居民申请香港汇丰银行卡流程记录

Memos: 终章之为 GG 卡选择一个慈善 PLAN

Memos: GG 卡 GG

Memos: 苹果系统在它工作的时候会工作的很好

Memos: 昨天发现 caffeinate -i 能避免休眠

Memos: 多 子 多 福

Memos: 精 打 细 算

Memos: 反 客 为 主

Memos: 形 同 虚 设

Memos: Grok Build 可以试试

Memos: 谁不想用自己媳妇儿的形象做个电子 “Pet” 呢

Memos: 洗碗机太大，洗碗机太小

从无脑缓存并发到数据库仅索引查询

Memos: 记录当下基于 AI 御三家基础订阅的编程流程

Memos: 快跑！说美国豆包是过誉了

Memos: 使用 rtk-ai/rtk 一个多月后的统计

Memos: 大意了！1.5x2.0 米的床

云南系列｜Day 7 返程前在丽江的一天

Memos: Upyun CDN 下线 HTTP/3 支持

云南系列｜Day 5、6 在沙溪古镇的两天

云南系列｜Day 4 剑川古城记录

云南系列｜Day 3 周城扎染 & 抵达剑川

Memos: 多子多福

Memos: 精打细算

Memos: 反客为主

Memos: 形同虚设