评论图片直传图床：Waline + EdgeOne 边缘函数踩坑记

坑一：HTTP 545——函数明明部署成功了#

现象很刁钻：GET / 返回 200，OPTIONS 预检返回 204，唯独 POST /upload 全部返回 545。查了半天才知道这是 EdgeOne 的平台层错误码，意思是”脚本执行出错”——函数里抛了没接住的异常。

可函数逻辑看着没问题？真正的坑在环境变量的取法。EO 的文档里，Pages 函数从 context.env 取环境变量，站点级边缘函数的文档里又是全局 env——我按前者写了 const { request, env } = context，结果在部署形态下 env 是 undefined。而代码里只有 POST 路径会先碰 env.ALLOWED_ORIGINS，GET 路径在那之前就返回了——这完美解释了”GET 正常、POST 炸”的诡异不对称。

修复两手一起抓：

1
// 兼容两种环境变量形态
2
const readEnv = (context) => {
3
  if (context?.env && typeof context.env === "object") return context.env;
4
  if (typeof env !== "undefined" && env) return env;
5
  return {};
6
};
7

8
// 全局兜底：任何异常都转成 500 + 错误信息，而不是平台层 545
9
export async function onRequest(context) {
10
  try {
11
    return await handle(context);
12
  } catch (err) {
13
    return json({ error: `上传服务内部错误：${err?.message}` }, 500, "*");
14
  }
15
}

教训：边缘函数里别让任何异常裸奔到平台层——545 不会告诉你任何事，自己包一层 500 才能看见堆栈。

坑二：401——Token 和 authCode 是两种鉴权#

545 修完，POST 终于能穿透到图床了，结果图床回 401 Unauthorized。

我拿鉴权码直连图床测了两种姿势：放进 ?authCode= 查询参数 → 401；放进 Authorization: Bearer 请求头 → 200。真相大白：我手里的是图床后台签发的 API Token（imgbed_ 前缀），它只认请求头；authCode 查询参数是另一种环境变量式的鉴权码，两者不是一回事。

函数里干脆两个都带上，图床那边任一命中即可通过，以后换哪种凭证都不用改代码：

1
target.searchParams.set("authCode", E.AUTH_CODE);      // 鉴权码式
2
headers = { authorization: `Bearer ${E.AUTH_CODE}` };  // API Token 式

坑三：404 之谜——直连全通，代理必挂#

这是最磨人的一关。修复 401 后，三层测试变成了：无 Origin → 403 ✅，带 Origin 缺文件 → 400 ✅，全链路上传 → 图床返回 404 ❌。

诡异在于我用 curl 逐字节复刻代理的请求——同一个 URL、同样的查询参数、同样的 Bearer 头、同一个文件——直连怎么测都是 200，只有从边缘函数发出去才 404。URL 没错（res.url 显示落在 a.xxx.com/upload，没有重定向），文件也没错（名字、类型、大小都完好）。

排查手段是把函数的错误响应加厚：图床返回非 2xx 时，把实际落地路径、原始响应体、收到的文件元信息全部带回来。加上之后信息还是很干净——那就只剩一个变量了：请求体本身。

结论：EO 运行时对 FormData 的 multipart 序列化和标准实现有差异，序列化出来的报文图床（也是跑在 CF Pages 上）解析不了，解析失败直接 404。既然运行时的 FormData 不可信，就自己按 RFC 拼字节流：

1
async function buildMultipart(file, filename, fileType) {
2
  const boundary = `----EOUpload${Date.now().toString(36)}`;
3
  const head = new TextEncoder().encode(
4
    `--${boundary}\r\n` +
5
      `Content-Disposition: form-data; name="file"; filename="${filename}"\r\n` +
6
      `Content-Type: ${fileType}\r\n\r\n`,
7
  );
8
  const fileBytes = new Uint8Array(await file.arrayBuffer());
9
  const tail = new TextEncoder().encode(`\r\n--${boundary}--\r\n`);
10
  const body = new Uint8Array(head.byteLength + fileBytes.byteLength + tail.byteLength);
11
  body.set(head, 0);
12
  body.set(fileBytes, head.byteLength);
13
  body.set(tail, head.byteLength + fileBytes.byteLength);
14
  return { body, contentType: `multipart/form-data; boundary=${boundary}` };
15
}

函数里做成自动降级：先用 FormData 转发，非 2xx 就用手搓 multipart 重试一次，再失败才报错。部署完重测，全链路 200，返回 {"url":"https://tu.xxx.com/file/waline/xxx.png"}——通了。

教训：不同边缘运行时的 Web API 兼容性不能想当然，“标准里应该这样”和”这个运行时实际这样”是两回事。把原始响应体带出来比反复猜快得多。

坑四：设计坑——“点发送才上传”的假链接#

这个坑是我自己挖的。最初有个想法：图片不要在选的时候就传，等用户点发送时再批量上传——这样发评论前删掉的图就不会产生上传。

实现思路：imageUploader 立即返回一个假占位链接（形如 pending://uuid/文件名），文件暂存内存；再在容器捕获阶段拦截 Waline 的两条提交路径（发送按钮 click 和 Ctrl/Cmd+Enter），拦截后先把内存里的文件全部上传、把编辑器文本里的占位替换成真实链接，最后放行原生提交。

功能上跑通了，但编辑器里从此躺着一个 pending:// 假链接，怎么看怎么别扭。真正判它死刑的是后来读 Waline 源码时发现的雷：Waline 会把编辑器草稿存进 localStorage。如果选完图没发送就刷新页面，草稿恢复出 pending:// 文本，但内存里的待传文件早没了——此时点发送，占位链接会被原样发布，评论区永远显示一个死链。

而读源码的同一时刻也发现：Waline 原生机制早就把”上传中”的体验做全了（占位、锁定、替换、失败处理，见前文）。所谓”点发送才上传”省下的那点体验，撑不起这些假链接和漏洞。于是整个拦截层删掉，回到选图即传，净删近百行。