2026-09-10 12:05:16
自 2026 年 7 月起，北京市职工基本养老、失业、工伤及职工基本医疗保险（含生育）的月缴费基数上限和下限分别为：
相比 2025 年，下限由 7162 元上调至 7270 元，增加 108 元，涨幅约 1.51%；上限由 35811 元上调至 36348 元，增加 537 元，涨幅约 1.50%。
按 7270 元缴费基数，个体工商户以企业身份为经营者缴纳社保，承担单位和个人两部分费用明细如下：
作为对比，2025 年社保基数调整后，个体工商户最低缴费由 2540.42 元/月上升至 2667.27 元/月（上涨 126.85 元/月）。
数据来源
2026-09-09 17:00:23
这两天使用 AI（GPT 5.6 Luna High 模型）做了两个测试：
早些年客户端会通过各种奇淫巧技将密钥等信息藏起来，现在感觉意义不太大了，服务安全评估应该假定客户端密钥、接口逻辑均暴露在 Github 上时，服务端是否仍能足够安全。
2026-09-05 21:34:00
有这样一个场景，客户端调用服务端 API 兑换奖励：
POST /api/v1/redemptions
{
"reward_id": "id-123"
}用户发起一次商品兑换请求，因网络等因素，客户端不清楚是否处理成功，可能会发起重试，假设前一个请求在服务端已经成功，只是在返回途中丢失，客户端重试时，服务端没办法判断是客户端重试还是用户发起的第二次兑换请求。
结合业务场景，以下方式可能在一定程度上缓解问题，如：
行业内正规的做法是借助 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” 建立唯一约束。如果仅仅为了解决短时间重试、重复点击问题，可以将缓存设置为几分钟，但并发场景需要原子化处理，并发问题等下篇再记录。
另外也可以在中间件上做文章，按接口的重要程度设置不同的缓存时间或持久化存储策略。
上方设计了缓存键，能否将 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 偷偷换了请求内容”。
了解以上内容，接口幂等键的设计就不会有大方向上的问题了，但对于幂等键，还有一些需要掌握的。
幂等与幂等键
不要混淆，两者是不同的概念。
适用的 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 请求中发送幂等键，因为这样做不会产生任何效果。这些请求根据定义本身就是幂等的。）
关于幂等键的记录，就先到这里。
2026-09-03 19:04:23
两个月前在闲鱼购买了个 18 月的 Google AI Pro 订阅，使用小号领取。
而后下载 Gemini Cli，登录后网页提示验证，提示需要输入手机号，一直没办法通过验证，就闲置下来，Google 发了新的 Gemini 3.8 Flash 模型听说不错，想着再试试，下载 Antigravity Cli，走登录流程、提示扫码，验证成功。
重点：
2026-09-02 18:10:23
同事推荐的，我下载试了试，可以连接到 ChatGPT、Cursor、Claude..及各种订阅，使用其订阅额度。
相较于 ChatGPT（Codex），使用同样的 OpenAI 的 5.6 Luna High，OMP 运行流畅、速度更快。
Github 仓库：can1357/oh-my-pi
2026-09-01 10:35:00
本月公司订阅的 Cursor Team 计费方案变更，从按次每月 500 点数变为按量计费 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 天。