这是 SCF（云函数）的部署包限制：代码包 zip 压缩后 128MB，解压后上限 512MB（含层）。超限的三条路，按成本排序： 1）依赖瘦身：node_modules 走 prune、Python 只装生产依赖、排除测试与文档——实际业务里 80% 的超包是依赖没清理，先做这个再评估架构； 2）用「层」（Layer）拆分：把大依赖（numpy/pandas、puppeteer 的 chromium、字体文件）放到层里，多个函数共享引用，主包只留业务代码——层不计入代码包大小； 3）改容器镜像部署：SCF 支持镜像部署，上限大得多，适合真带大依赖（AI 模型文件、headless 浏览器）的场景，代价是冷启动变慢，要配合预留实例。 另外注意两点：压缩包先优化再动架构（zip 的 128M 是压缩后限制，文本类依赖压缩率很高）；冷启动敏感的函数慎用大镜像，预留实例与并发限流要配套。... 展开详请

先泼个冷水：workers.dev 这个域名对云机房 IP 很不友好，Cloudflare 对来自数据中心 IP 的请求风控很重，而 EO 回源节点全是机房 IP，握手被丢包或直接 RST 太常见了，522 多半不是你配置错，是对端在拒你。验证很简单：找台云服务器 curl -v 那个 workers.dev 地址多试几次，再用家庭宽带对比访问，机房必挂基本就实锤了。解法两条：给 Worker 绑自己的自定义域名走 CF 接入，风控策略宽松很多；或者干脆把同样的逻辑搬到 EO 边缘函数里实现，去掉跨云回源这一跳，延迟和稳定性都更好，也省得两头排查。... 展开详请

avoidSizeIncrease 的逻辑是转换后的体积比原图还大时，直接返回原图不处理。你看到的「空」多半不是真空，而是边缘函数把这个未处理的分支当异常吞了。排查：先用 curl 单测同一张图，看响应的 Content-Type 和 body 到底是原图还是空，确认函数里对这个分支有没有兜底返回。另外 WebP、AVIF 这类格式在小尺寸或低质量参数下，转换后体积确实可能变大，正好触发这个开关。建议小图直接跳过处理，或者把质量参数改成条件式的，别让开关替你做隐式决定。... 展开详请

EdgeOne免费版的回源策略是轮询（Round Robin），不区分运营商，跨网回源确实可能导致性能下降。 **一、EdgeOne免费版回源机制** 用户请求到EdgeOne边缘节点（就近分配）再回源到源站IP。多源IP场景为轮询，不区分运营商。免费版不支持按运营商智能路由回源。 **二、为什么跨网回源会慢** 中国运营商之间互联带宽有限：电信源站到联通节点回源需经过互联关口，拥塞时延迟增加50-200ms，丢包率上升，大文件传输速度可能下降50%以上。 **三、优化方案** 方案1：源站部署多线BGP（推荐） BGP源站同时广播电信+联通+移动IP，EdgeOne任何节点的回源都能走同网路径。腾讯云CVM的BGP带宽本身就是多线的，源站在腾讯云基本不存在这个问题。 方案2：源站前置对象存储 静态内容直接放到腾讯云COS，让EdgeOne回源到COS。用户到EdgeOne边缘节点到腾讯云COS（内网回源，无跨网问题）。在EdgeOne控制台-站点加速-源站配置，源站类型选择"对象存储源站（COS）"，填入COS Bucket域名。免费版也支持。 方案3：源站使用智能DNS 通过智能DNS让不同运营商的节点解析到同运营商的源站IP，但EdgeOne回源时DNS解析在递归DNS上完成，不一定保证运营商匹配。 **四、实际建议** - 源站在腾讯云：无跨网问题，内网回源 - 源站在其他云：可能有跨网，建议迁移或用BGP - 源站在自建机房(单线)：跨网严重，建议上云或加BGP - 静态内容：迁移到COS，彻底解决 **结论**：最有效的方案是把源站放到腾讯云（CVM或COS），利用内网回源消除跨网问题。静态内容直接用COS作为源站是最佳方案。... 展开详请