一、为什么中间必须站一个 Worker#

先看三个”直接就能用”的思路，全部实测过：

第一条是决定性的。实测一下就很清楚：

1
curl -sI 'https://cn.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1&mkt=zh-CN' | grep -i access-control
2
# （无输出）

浏览器发起的跨域 fetch 拿不到响应体，no-cors 模式下又读不出内容。这个接口天生只能由服务端调用——不是”可以加个代理更优雅”，而是”不加代理根本拿不到”。

所以链路变成了：

1
浏览器 ──<img src>──> Worker（302）──> cn.bing.com 的图片 CDN
2
                        └─ 边缘缓存着调一次元数据 API

这里有个值得单独说的设计：Worker 只做 302，不搬运图片字节。

• 图片流量直接由浏览器连 Bing CDN，Worker 完全不参与传输；
• Worker 一天真正”干活”的次数约等于零（元数据被边缘缓存住，cacheTtl: 1800）；
• 免费额度（10 万请求/天）对这个用法来说是天文数字。

如果改成 Worker 拉图再回吐（fetch 图片然后 Response 出来），带宽会全部记在 Worker 账上，收益是零。302 是这里唯一正确的姿态。

二、Bing 的接口真实长什么样#

format=js 时的响应（2026-09-19 实测截取）：

1
{
2
  "images": [
3
    {
4
      "startdate": "20260918",
5
      "urlbase": "/th?id=OHR.AlphornBavaria_ZH-CN5896237112",
6
      "copyright": "阿尔卑斯长号演奏者，巴伐利亚州，德国 (© U. J. Alexander/Shutterstock)",
7
      "copyrightlink": "https://www.bing.com/search?q=..."
8
    }
9
  ]
10
}

真正要用的只有三个字段：

1
https://cn.bing.com/th?id=OHR.AlphornBavaria_ZH-CN5896237112_1920x1080.jpg&pid=hp&w=1920&h=1080
2
                                                      └───── 档位 ─────┘ └── 尺寸参数 ──┘

1
阿尔卑斯长号演奏者，巴伐利亚州，德国 (© U. J. Alexander/Shutterstock)

1
// 匹配开头的任意非中文冒号内容 + 冒号
2
function cleanCredit(raw?: string): string {
3
  return str(raw).replace(/^[^：:]*[：:]\s*/, "");
4
}

三、三级兜底链：Banner 不能白板#

banner 是首屏第一眼。它挂了，整站看起来就像没做完。所以这里的兜底不是”锦上添花”，而是必须项：

1
async function isReachable(url: string): Promise<boolean> {
2
  try {
3
    const res = await fetch(url, { method: "HEAD", cf: { cacheTtl: 300, cacheEverything: true } });
4
    return res.ok;
5
  } catch {
6
    return false;
7
  }
8
}

1
function placeholderSvg(): string {
2
  return '<svg xmlns="http://www.w3.org/2000/svg" width="1920" height="1080" viewBox="0 0 1920 1080">'
3
    + '<defs><linearGradient id="g" x1="0" y1="0" x2="1" y2="1">'
4
    + '<stop offset="0" stop-color="#2a3f5f"/><stop offset="0.55" stop-color="#1b2a41"/>'
5
    + '<stop offset="1" stop-color="#0f1a2b"/></linearGradient></defs>'
6
    + '<rect width="1920" height="1080" fill="url(#g)"/></svg>';
7
}

四、/fallback：把”等它挂”变成一条命令#

三级兜底链有个尴尬：平时永远测不到。第 2、3 级只有在 Bing 真挂的那天才会触发，而你想在出事前确认它可用时，只能干等。

所以专门开了一个端点：

1
GET /fallback   →  不管 Bing 死活，直接命中兜底链的第 2/3 级

它带两个响应头说明自己走的是哪一级：

1
X-Fallback: custom        # 命中了自备兜底图
2
X-Fallback-Reason: manual # 手动触发（自动触发时是 bing-unavailable）
3

4
X-Fallback: svg           # 自备图也没探通，退回内置 SVG

现在验证兜底链是一条命令的事：

1
node -e "const r=await fetch('https://bing.142588.xyz/fallback',{redirect:'manual'});console.log(r.status, r.headers.get('x-fallback'), r.headers.get('location'))"

这个设计的价值在于：可测的兜底才算兜底。 一段”只会在故障时执行、且从没被执行过”的代码，是没被验证过的代码。

五、Worker 端的四个取舍#

整份实现 265 行、零依赖——wrangler deploy 上去的就是自己那份 index.ts。几个刻意的选择：

① 不引框架。 四个端点、一个 switch 就够了。上 Hono 会让”部署的产物”和”能读懂的代码”之间多隔一层。

② 边缘缓存元数据。 调 Bing 那次 fetch 带 cacheTtl: 1800，只有到期的第一次请求会真正回源。一天 48 次，不是”每个访客一次”。

③ CORS 只给 /meta。 只有它需要被前端 fetch（换署名），图片路径是 302 跳转，根本不需要 CORS 头。ALLOWED_ORIGINS 走白名单而不是 *。

④ 跳转本身也缓存。 302 带 Cache-Control: public, max-age=3600，浏览器和中间层一小时才回来问一次。

六、前端三步#

后端通了，前端只剩三件事——但每件都有一个”不做就静默失效”的坑。

1
banner: {
2
  enable: true,
3
  src: "https://bing.142588.xyz/today",
4
  credit: { enable: true, text: "Bing 每日壁纸", url: "https://www.bing.com" },
5
}

1
const bannerMetaUrl = siteConfig.banner.src.replace(/\/today\/?$/, "/meta");

1
{enableBanner && bannerOrigin && (
2
  <>
3
    <link rel="preconnect" href={bannerOrigin} />
4
    <link rel="preconnect" href="https://cn.bing.com" />
5
  </>
6
)}

七、部署：两个非写不可的细节#

1
cd workers/bing-banner
2
env -u CLOUDFLARE_API_TOKEN -u CLOUDFLARE_ACCOUNT_ID npx -y wrangler deploy

① 必须清掉那两个环境变量。 本机环境里它们存在但无效，不清掉会直接报认证错误 10000。这个坑的本站记录在另一篇文章里也出现过——凡是 wrangler deploy 报 10000，先 env -u 再跑。

② workers.dev 域名必须放弃。 它在国内被 DNS 污染，直连不通。配置里用 custom_domain: true 挂自有域名：

1
"routes": [
2
  { "pattern": "bing.142588.xyz", "custom_domain": true }
3
]

custom_domain: true 会让 wrangler 自动创建 DNS 记录与证书，不用手动去控制台点。

八、为什么没用 Unsplash#

Unsplash 看起来是更”正规”的选择：图片许可干净（Unsplash License，可商用）。但实测下来，做 banner 图源它反而更麻烦：

三个结论：

• 稳定性上 Bing 完胜：不需要 key、不需要注册、不会因为配额或接口下线而挂（source.unsplash.com 的前车之鉴就在眼前）。
• 体积上两者接近（231 KB vs 250 KB），所以”省流量”不是选 Bing 的理由。
• 法律上 Unsplash 更干净。Bing 的图版权归摄影师和 Shutterstock，Bing 官方 tooltip 甚至写着”此图片不能下载用作壁纸”。个人博客非商业使用属于灰色地带，缓解方式是把署名显示出来（本项目 credit 就是干这个的），但这不是免责。

如果这个站将来要商业化，正确做法是换成 Unsplash / Pexels 这类明确授权的图源，或者干脆换成自绘的 banner。技术链路（Worker + 兜底链 + 302）可以原样复用，只改 FALLBACK_URL 和第 1 级的取图逻辑。

另外，兜底图本身就选了一张 Unsplash License 的图（山峦云海，1920×1080 / webp q82 / 259 KB，托管在自有图床）——万一哪天真要撤掉 Bing，第 2 级已经在跑一张合法图了。

九、踩坑清单#

十、验证#

整套逻辑可以完全离线验证，不需要部署、不需要起服务：

1
node .workbuddy/tools/verify-bing-banner.mjs   # 71 项

它用打桩的方式覆盖了：四种端点路由、302 的 Location 拼接、&w=&h 参数是否带上、CORS 白名单命中与不命中、五种故障模式是否都落到兜底链、X-Fallback 头是否正确、内置 SVG 是否合法且无外部引用。

线上快速探活（含兜底链）：

1
node -e "const r=await fetch('https://bing.142588.xyz/today',{redirect:'manual'});console.log(r.status, r.headers.get('location'))"

小结#

整件事的核心可以压缩成三句话：

1. 中间层不是封装，是必需品——Bing 的元数据接口没有 CORS 头，浏览器端根本拿不到数据。
2. Worker 只做 302，不搬字节——图片流量直连 Bing CDN，Worker 一天真正干活的次数屈指可数。
3. 兜底必须可测——三级兜底链 + 一个专门用来手动命中它的 /fallback 端点。

最终成果：首页 banner 每天自动换图、显示摄影师署名、不需要重新构建、Bing 挂了也不会白板——代价是 265 行代码和一个自有子域名。

参考与致谢#

• 接口：Bing HPImageArchive.aspx（本文所有档位与体积数据均实测自该接口当天返回的图片）
• 兜底图：Unsplash License，源图 ID photo-1470071459604-3b5ec3a7fe05
• Banner 组件：Fuwari 原生的 ImageWrapper.astro / siteConfig.banner