2026-08-05

今日主题

• git clone 对象打包机制
• launchd 用户级自启动机制
• Serverless 与 FaaS 的关系
• HTTP 认证挑战与 OAuth 发现

新增认知

git clone 对象打包机制

• 枚举与计数是不同角色：
  git clone 输出里 Enumerating objects（如 261198）和 Counting objects（如 75）不是对同一批对象做两次清点，
  不能按数量大小理解成子集关系。Enumerating 是服务端计算「clone 需要发送的完整可达对象集合」；
  Counting 是 pack-objects 阶段统计「本次生成传输 pack 时真正要处理的对象数」，两者统计口径本质不同——
  后者小不代表是从前者里抽样或只挑了新增对象。

• 数量悬殊源于 pack bitmap 复用：Counting objects 远小于 Enumerating objects，
  根本原因通常是服务端启用了 reachability bitmap，使得历史对象可以直接复用已有 pack 文件（pack-reuse）打包发送，
  完全跳过逐个计数与压缩；
  只有 bitmap 未覆盖的少量对象（如最近新增、尚未打包的松散对象）才会真正进入 Counting/Compressing 这条 pack-objects 内部流水线。
  这是 GitHub 等大型 git 服务端的常见优化，本地 git gc/repack 因为要重建整个仓库的 pack，没有这种复用，
  所以 Counting 会等于全部对象数。

• 排查内部机制先看有无优化路径复用：分析工具输出中「某阶段数字远小于预期总数」这类现象时，比起把小数字理解成「新增/未处理的一部分」，
  更应先怀疑是否存在缓存或复用机制（如这里的 pack bitmap）绕过了大部分工作量，只有边界外的少量数据才真正被处理——
  这类因果关系比单纯的子集抽样解释更常见，也更准确。

launchd 用户级自启动机制

• LaunchAgent 而非 LaunchDaemon：
  macOS 的"开机自启动"对用户级程序实际对应 launchd 的 LaunchAgent（登录时启动，
  plist 放在 ~/Library/LaunchAgents），而非 LaunchDaemon（系统级、开机即启、通常需要 root）。
  判断依据是程序是否需要用户会话上下文（如本例中要驱动浏览器扩展），这类场景必须用 LaunchAgent。

• KeepAlive 要匹配程序的自后台化行为：
  若目标程序的启动命令自身会 fork 到后台并让父进程退出（如本例 kimi-webbridge start），
  plist 中只能设 RunAtLoad=true，不能设 KeepAlive=true——否则 launchd 会因为检测到"进程退出"而不断重新拉起父进程，
  造成重复启动循环。配置前需要先验证该命令是否幂等（重复执行时对已运行实例是安全跳过还是报错），这决定了 RunAtLoad 单独使用是否安全。

Serverless 与 FaaS 的关系

• FaaS 是 Serverless 的子集：FaaS（Function as a Service）是一种具体的计算产品形态，
  运行单位是函数/handler；Serverless 是更大的架构模式，指基础设施由平台托管、按用量计费、可缩容到零，
  涵盖计算之外的数据库、消息队列、对象存储等。因此 FaaS ⊂ Serverless：FaaS 回答"代码怎么运行"，
  Serverless 回答"基础设施由谁管、怎么扩容计费"。

• 判断标准看运行单位是否必须是函数：区分两者的关键前置条件是"是否要求代码长成 handler 函数"。以 Cloud Run 为例，
  它是 Serverless（自动扩缩容、无请求缩到零、按用量计费），但运行的是完整容器/普通 HTTP 服务（如 http.ListenAndServe），
  不要求写成 func handler(event)，所以不算传统 FaaS。这说明 Serverless 不代表只能提交函数，
  但 FaaS 一定是 Serverless 的一种强特征体现。

• 混淆根源是厂商术语泛化：
  很多文章把自家 FaaS 产品直接简称为"Serverless"（如"用 Serverless 处理图片上传"实际是触发 Lambda），
  把具体实现和更大的类别名混用。这类似于把"买了一台云服务器"说成"用了云计算"——说法不算错但不精确，
  理解时要按语境还原到具体是 FaaS 还是更广义的 Serverless。

HTTP 认证挑战与 OAuth 发现

• 认证与授权分层：Authentication 回答“你是谁”，Authorization 回答“你能做什么”。前者验证身份或凭证真实性，
  后者判断已识别主体是否拥有操作权限；工程中常用 AuthN 与 AuthZ 区分，两者相关但不能互换。

• 挑战是认证要求：WWW-Authenticate 中的 challenge 不是自然语言里的挑衅，而是服务端提出的结构化身份验证要求。
  客户端收到 401 后，根据认证方案和参数取得或提交凭证，再重试受保护资源；它与 302 加 Location 都提供后续信息，但前者要求证明身份，
  后者要求改换请求地址。

• 字段具有固定结构：WWW-Authenticate 的值由认证方案和命名参数组成，
  例如 Bearer、realm、scope 和 resource_metadata，因此客户端可以按协议解析，而不是猜测一段提示文本。
  realm 表示凭证适用的认证区域，并不意味着用户拥有同名角色或权限。

• 元数据负责发现：resource_metadata 是 RFC 9728 定义的标准 challenge 参数，并非 MCP 自创。
  MCP 用它定位 Protected Resource Metadata，
  从中发现受保护资源信任的 Authorization Server 及总体支持的 scopes；
  challenge 里的 scope 则描述当前操作具体需要的权限，两者分别解决“去哪里了解授权体系”和“这次需要什么权限”。