Cloudflare Sandbox 避坑指南常见错误、性能优化与安全最佳实践全解析【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本篇指南围绕 Cloudflare Sandbox SDK 在边缘容器中运行不可信代码时的实战痛点展开系统梳理了容器无限运行CONTAINER_NOT_READY预览 URL 失效文件不持久化等高频错误的成因与解决方案并给出沙箱 ID 复用、sleepAfter 成本调优、命令注入防护与密钥管理等可直接落地的代码级最佳实践。读完本文你将掌握 Cloudflare Sandbox 的限流与超时边界能够在自己的 Worker 项目中稳定、安全、低成本地运行隔离容器。一、背景为什么需要一份 Gotchas 清单Cloudflare Sandbox 允许在边缘侧基于 Durable Object Container 的架构安全地执行不受信任的代码典型场景包括 AI 代码执行、交互式开发环境、数据分析、CI/CD 与多租户执行。它虽然 API 简洁核心入口见 sandbox/README.md但容器生命周期、Durable Object ID、端口暴露、睡眠唤醒等机制存在大量文档之外的细节——gotchas.md本文档位于 sandbox/gotchas.md正是对这些已知陷阱与最佳实践的权威汇总。下文所有示例均可直接复制运行相关 API 定义可对照 sandbox/api.md 与 sandbox/configuration.md 查阅。二、常见错误与解决方案1. Container running indefinitely容器无限运行成因开启了keepAlive: true却从未调用destroy()容器永不进入睡眠资源持续占用并产生持续费用。解决方案使用keepAlive: true的容器必须在用完后的finally块中显式调用destroy()释放资源const sandbox getSandbox(env.Sandbox, temp, { keepAlive: true }); try { const result await sandbox.exec(python script.py); return result.stdout; } finally { await sandbox.destroy(); // REQUIRED to free resources }根据 api.md 生命周期管理 的说明destroy()会一并删除文件、进程、会话、网络连接和已暴露的端口因此用完即毁是保持容器干净的唯一可靠途径。2. CONTAINER_NOT_READY成因容器仍在供给首次请求或从睡眠中唤醒时此时exec尚未就绪。解决方案等待 23 秒后重试。以下是推荐的指数重试封装async function execWithRetry(sandbox, cmd) { for (let i 0; i 3; i) { try { return await sandbox.exec(cmd); } catch (e) { if (e.code CONTAINER_NOT_READY) { await new Promise(r setTimeout(r, 2000)); continue; } throw e; } } }在 api.md 的错误处理 中CONTAINER_NOT_READY是 SDK 定义的标准错误码之一官方同样建议针对它做重试处理SDK 抛出的错误还包含FILE_NOT_FOUND、TIMEOUT等可分支处理的错误码。3. Connection refused: container port not found成因Dockerfile 中缺少EXPOSE指令wrangler dev本地开发时无法访问容器端口。解决方案在 Dockerfile 中显式添加EXPOSE port。注意此限制仅存在于本地wrangler dev——生产环境会自动暴露所有端口详见 configuration.md 的 Dockerfile 模式FROM docker.io/cloudflare/sandbox:latest RUN pip3 install --no-cache-dir pandas numpy matplotlib EXPOSE 8080 3000 # Required for wrangler dev4. Preview URLs not working预览 URL 无法访问成因通常由以下四类配置缺失之一引起——未配置自定义域名、缺少泛域名 DNS、normalizeId未开启或proxyToSandbox()未被调用。解决方案按清单逐项排查是否配置了自定义域名不支持.workers.dev域名泛域名 DNS 是否正确指向*.domain.com → worker.domain.comgetSandbox中是否设置了normalizeId: truefetch处理器中是否最先调用了proxyToSandbox()。关于第 4 点sandbox/README.md 的快速开始 明确强调CRITICAL:proxyToSandboxMUST be called first for preview URLs即预览 URL 的代理请求必须由它在 fetch 入口处先行接管。5. Slow first request首请求缓慢成因冷启动——容器正处于供给阶段首次请求或从睡眠唤醒。解决方案三选一或组合使用使用sleepAfter让沙箱在空闲后进入睡眠而非销毁下次请求自动唤醒代价仅 23s 冷启动使用 Cron 触发器预热例如crons: [*/5 * * * *]每 5 分钟唤醒一次对关键沙箱设置keepAlive: true必须配套destroy()。Cron 预热的完整实现可参考 configuration.md 的 Cron Triggers其原理是在scheduled处理器中执行一次echo keepalive之类的轻量命令来唤醒容器。6. File not persisting文件不持久化成因文件写入了/tmp等临时路径容器磁盘本身是易失的。解决方案持久化文件统一使用/workspace。这与 patterns.md 中所有示例的目录约定一致——无论是 CI/CD 克隆仓库到/workspace/repo还是多租户会话以/workspace/users/${userId}作为工作目录/workspace都是事实上的持久化根目录。7. Bucket mounting doesnt work locally本地桶挂载失效成因桶挂载依赖 FUSE 内核模块而wrangler dev本地环境不可用。解决方案桶挂载仅在生产环境可用本地开发请使用 mock 数据替代。相关 APImountBucket/unmountBucket及生产环境专用的说明见 api.md 的 Bucket Mountingpatterns.md 的持久化数据模式 也给出了挂载 R2 桶到/data的完整示例。8. Different normalizeId different sandboxnormalizeId 不一致导致换了沙箱成因normalizeId选项会改变 Durable Object ID 的生成方式——开启后 ID 会被小写化导致相同业务 ID 映射到完全不同的沙箱。解决方案normalizeId必须全局保持一致。注意下面两段代码创建的是不同的沙箱// These create DIFFERENT sandboxes: getSandbox(env.Sandbox, MyApp); // DO ID: hash(MyApp) getSandbox(env.Sandbox, MyApp, { normalizeId: true }); // DO ID: hash(myapp)从仓库参考看normalizeId: true不仅是预览 URL 的前置条件见 configuration.md 的 Preview URL Setup还会影响沙箱 ID 的确定性因此一旦选定就必须在应用内所有getSandbox调用处保持一致。9. Code context variables disappeared代码上下文变量消失成因容器重启睡眠/唤醒周期会清空代码上下文Code Context的状态。解决方案代码上下文是易失的容器睡眠/唤醒后必须重建上下文。createCodeContext创建的上下文变量在沙箱存活期内可跨多次runCode调用保持但无法跨容器生命周期存活这是设计使然详见 api.md 的 Code Interpreter 与 patterns.md 的 AI 代码执行模式。三、性能优化让沙箱又快又省沙箱 ID 策略沙箱的持久性与复用完全由 ID 决定同 ID 同一沙箱。切忌每次请求都生成新 ID这会反复触发冷启动// ❌ BAD: New sandbox every time (slow) const sandbox getSandbox(env.Sandbox, user-${Date.now()}); // ✅ GOOD: Reuse per user const sandbox getSandbox(env.Sandbox, user-${userId});这一策略在多租户场景下尤其关键按租户维度复用沙箱 ID既保证状态隔离又避免了不必要的容器供给开销。睡眠与流量配置成本与延迟的权衡核心在两个选项sleepAfter空闲多久后睡眠与keepAlive是否永不睡眠// Cost-optimized成本优先空闲 30 分钟后睡眠 getSandbox(env.Sandbox, id, { sleepAfter: 30m, keepAlive: false }); // Always-on常驻不睡眠必须配套 destroy() getSandbox(env.Sandbox, id, { keepAlive: true });sleepAfter支持5m、1h、2d等时长字符串默认值10m睡眠中的沙箱会在下次请求时自动唤醒冷启动 23s。完整的参数语义见 configuration.md 的 getSandbox Options。高流量场景下还可以通过wrangler.jsonc提升并发实例上限// High traffic: increase max_instances { containers: [{ class_name: Sandbox, max_instances: 50 }] }四、安全最佳实践沙箱隔离每个沙箱 一个完全隔离的容器独立的文件系统、网络与进程命名空间多租户应用务必按租户使用唯一沙箱 ID防止跨租户状态串扰沙箱之间不能直接通信天然提供了网络级隔离边界。输入验证防御命令注入严禁将用户输入直接拼接到 shell 命令中执行——这是最典型的命令注入面// ❌ DANGEROUS: Command injection const result await sandbox.exec(python3 -c ${userCode}); // ✅ SAFE: Write to file, execute file await sandbox.writeFile(/workspace/user_code.py, userCode); const result await sandbox.exec(python3 /workspace/user_code.py);正确姿势是先写文件、再执行文件同时配合 patterns.md 的多租户模式 中按用户拆分会话与工作目录的做法进一步收敛攻击面。资源限制为长任务设置超时默认情况下exec()的超时上限为 120 秒但建议显式为可能失控的命令设置更短超时// Timeout long-running commands const result await sandbox.exec(python3 script.py, { timeout: 30000 // 30 seconds });密钥管理永不硬编码禁止在代码中硬编码 token一律通过wrangler secret put KEY注入环境变量再以env.GITHUB_TOKEN读取通过exec的env选项按需传给沙箱内的进程// ❌ NEVER hardcode secrets const token ghp_abc123; // ✅ Use environment secrets const token env.GITHUB_TOKEN; // Pass to sandbox via exec env const result await sandbox.exec(git clone ..., { env: { GIT_TOKEN: token } });预览 URL 安全预览 URL 内置自动生成的访问令牌形如https://8080-sandbox-abc123def456.yourdomain.com令牌在每次 expose 操作时都会变化从而防止历史链接被未授权复用。这也解释了为什么预览 URL 必须满足自定义域名 泛域名 DNS normalizeId: true 先调用proxyToSandbox()四项前提。五、资源规格、超时与性能边界实例类型规格ResourceLiteStandardHeavyRAM256MB512MB1GBvCPU0.512对应wrangler.jsonc中containers[].instance_type字段默认值为lite详见 configuration.md 的 Instance Types。如果任务超出heavy规格说明应当拆分任务或选用 containers 参考文档 中规格更高的容器实例。操作超时与覆盖方式OperationDefault TimeoutOverrideContainer provisioning容器供给30sSANDBOX_INSTANCE_TIMEOUT_MSPort readiness端口就绪90sSANDBOX_PORT_TIMEOUT_MSexec()120stimeoutoptionsleepAfter10msleepAfteroption前两项超时既可以在getSandbox的containerTimeouts选项中逐沙箱覆盖instanceGetTimeoutMS/portReadyTimeoutMS见 configuration.md也可以通过wrangler.jsonc的vars全局覆盖{ vars: { SANDBOX_INSTANCE_TIMEOUT_MS: 60000, // Override instanceGetTimeoutMS SANDBOX_PORT_TIMEOUT_MS: 120000 // Override portReadyTimeoutMS } }性能基线首次部署容器镜像构建约需 23 分钟冷启动从睡眠唤醒约 23 秒桶挂载仅生产环境可用本地wrangler dev无 FUSE 支持。六、生产部署要点正式上线前请务必确认以下事项已闭环生产部署指南入口见 gotchas.md 原文 指向的官方 Production Guide预览 URL 四项前提全部就绪自定义域名、泛域名 DNS、normalizeId: true、proxyToSandbox()最先调用生命周期可回收所有keepAlive: true的沙箱都有对应的destroy()路径持久化位置正确业务数据写入/workspace桶数据走mountBucket仅生产超时参数经过压测按实际供给与端口就绪耗时配置containerTimeouts与环境变量覆盖。七、核心规则速查从本文全部案例中可以提炼出 Cloudflare Sandbox 的七条铁律总是最先调用proxyToSandbox()预览 URL 的前提同 ID 复用沙箱不要用时间戳破坏 ID 的确定性持久文件放/workspace/tmp随时可能消失预览 URL 必须normalizeId: true且全局保持一致CONTAINER_NOT_READY要重试而不是报错返回keepAlive: true必须配destroy()否则容器永不释放用户代码先写文件再执行杜绝命令注入。如需查看这些规则对应的完整 API 与配置可继续阅读仓库内的 sandbox/README.md、sandbox/api.md、sandbox/configuration.md 与 sandbox/patterns.md涉及容器运行时底层机制如startAndWaitForPorts、WebSocket 代理、sleepAfter活动超时续期可对照 containers 参考文档 进一步深入。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/12 16:58:58 · 阅读 1.2k Cloudflare Sandbox 避坑指南：常见错误、性能优化与安全最佳实践全解析
Cloudflare Sandbox 避坑指南常见错误、性能优化与安全最佳实践全解析【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本篇指南围绕 Cloudflare Sandbox SDK 在边缘容器中运行不可信代码时的实战痛点展开系统梳理了容器无限运行CONTAINER_NOT_READY预览 URL 失效文件不持久化等高频错误的成因与解决方案并给出沙箱 ID 复用、sleepAfter 成本调优、命令注入防护与密钥管理等可直接落地的代码级最佳实践。读完本文你将掌握 Cloudflare Sandbox 的限流与超时边界能够在自己的 Worker 项目中稳定、安全、低成本地运行隔离容器。一、背景为什么需要一份 Gotchas 清单Cloudflare Sandbox 允许在边缘侧基于 Durable Object Container 的架构安全地执行不受信任的代码典型场景包括 AI 代码执行、交互式开发环境、数据分析、CI/CD 与多租户执行。它虽然 API 简洁核心入口见 sandbox/README.md但容器生命周期、Durable Object ID、端口暴露、睡眠唤醒等机制存在大量文档之外的细节——gotchas.md本文档位于 sandbox/gotchas.md正是对这些已知陷阱与最佳实践的权威汇总。下文所有示例均可直接复制运行相关 API 定义可对照 sandbox/api.md 与 sandbox/configuration.md 查阅。二、常见错误与解决方案1. Container running indefinitely容器无限运行成因开启了keepAlive: true却从未调用destroy()容器永不进入睡眠资源持续占用并产生持续费用。解决方案使用keepAlive: true的容器必须在用完后的finally块中显式调用destroy()释放资源const sandbox getSandbox(env.Sandbox, temp, { keepAlive: true }); try { const result await sandbox.exec(python script.py); return result.stdout; } finally { await sandbox.destroy(); // REQUIRED to free resources }根据 api.md 生命周期管理 的说明destroy()会一并删除文件、进程、会话、网络连接和已暴露的端口因此用完即毁是保持容器干净的唯一可靠途径。2. CONTAINER_NOT_READY成因容器仍在供给首次请求或从睡眠中唤醒时此时exec尚未就绪。解决方案等待 23 秒后重试。以下是推荐的指数重试封装async function execWithRetry(sandbox, cmd) { for (let i 0; i 3; i) { try { return await sandbox.exec(cmd); } catch (e) { if (e.code CONTAINER_NOT_READY) { await new Promise(r setTimeout(r, 2000)); continue; } throw e; } } }在 api.md 的错误处理 中CONTAINER_NOT_READY是 SDK 定义的标准错误码之一官方同样建议针对它做重试处理SDK 抛出的错误还包含FILE_NOT_FOUND、TIMEOUT等可分支处理的错误码。3. Connection refused: container port not found成因Dockerfile 中缺少EXPOSE指令wrangler dev本地开发时无法访问容器端口。解决方案在 Dockerfile 中显式添加EXPOSE port。注意此限制仅存在于本地wrangler dev——生产环境会自动暴露所有端口详见 configuration.md 的 Dockerfile 模式FROM docker.io/cloudflare/sandbox:latest RUN pip3 install --no-cache-dir pandas numpy matplotlib EXPOSE 8080 3000 # Required for wrangler dev4. Preview URLs not working预览 URL 无法访问成因通常由以下四类配置缺失之一引起——未配置自定义域名、缺少泛域名 DNS、normalizeId未开启或proxyToSandbox()未被调用。解决方案按清单逐项排查是否配置了自定义域名不支持.workers.dev域名泛域名 DNS 是否正确指向*.domain.com → worker.domain.comgetSandbox中是否设置了normalizeId: truefetch处理器中是否最先调用了proxyToSandbox()。关于第 4 点sandbox/README.md 的快速开始 明确强调CRITICAL:proxyToSandboxMUST be called first for preview URLs即预览 URL 的代理请求必须由它在 fetch 入口处先行接管。5. Slow first request首请求缓慢成因冷启动——容器正处于供给阶段首次请求或从睡眠唤醒。解决方案三选一或组合使用使用sleepAfter让沙箱在空闲后进入睡眠而非销毁下次请求自动唤醒代价仅 23s 冷启动使用 Cron 触发器预热例如crons: [*/5 * * * *]每 5 分钟唤醒一次对关键沙箱设置keepAlive: true必须配套destroy()。Cron 预热的完整实现可参考 configuration.md 的 Cron Triggers其原理是在scheduled处理器中执行一次echo keepalive之类的轻量命令来唤醒容器。6. File not persisting文件不持久化成因文件写入了/tmp等临时路径容器磁盘本身是易失的。解决方案持久化文件统一使用/workspace。这与 patterns.md 中所有示例的目录约定一致——无论是 CI/CD 克隆仓库到/workspace/repo还是多租户会话以/workspace/users/${userId}作为工作目录/workspace都是事实上的持久化根目录。7. Bucket mounting doesnt work locally本地桶挂载失效成因桶挂载依赖 FUSE 内核模块而wrangler dev本地环境不可用。解决方案桶挂载仅在生产环境可用本地开发请使用 mock 数据替代。相关 APImountBucket/unmountBucket及生产环境专用的说明见 api.md 的 Bucket Mountingpatterns.md 的持久化数据模式 也给出了挂载 R2 桶到/data的完整示例。8. Different normalizeId different sandboxnormalizeId 不一致导致换了沙箱成因normalizeId选项会改变 Durable Object ID 的生成方式——开启后 ID 会被小写化导致相同业务 ID 映射到完全不同的沙箱。解决方案normalizeId必须全局保持一致。注意下面两段代码创建的是不同的沙箱// These create DIFFERENT sandboxes: getSandbox(env.Sandbox, MyApp); // DO ID: hash(MyApp) getSandbox(env.Sandbox, MyApp, { normalizeId: true }); // DO ID: hash(myapp)从仓库参考看normalizeId: true不仅是预览 URL 的前置条件见 configuration.md 的 Preview URL Setup还会影响沙箱 ID 的确定性因此一旦选定就必须在应用内所有getSandbox调用处保持一致。9. Code context variables disappeared代码上下文变量消失成因容器重启睡眠/唤醒周期会清空代码上下文Code Context的状态。解决方案代码上下文是易失的容器睡眠/唤醒后必须重建上下文。createCodeContext创建的上下文变量在沙箱存活期内可跨多次runCode调用保持但无法跨容器生命周期存活这是设计使然详见 api.md 的 Code Interpreter 与 patterns.md 的 AI 代码执行模式。三、性能优化让沙箱又快又省沙箱 ID 策略沙箱的持久性与复用完全由 ID 决定同 ID 同一沙箱。切忌每次请求都生成新 ID这会反复触发冷启动// ❌ BAD: New sandbox every time (slow) const sandbox getSandbox(env.Sandbox, user-${Date.now()}); // ✅ GOOD: Reuse per user const sandbox getSandbox(env.Sandbox, user-${userId});这一策略在多租户场景下尤其关键按租户维度复用沙箱 ID既保证状态隔离又避免了不必要的容器供给开销。睡眠与流量配置成本与延迟的权衡核心在两个选项sleepAfter空闲多久后睡眠与keepAlive是否永不睡眠// Cost-optimized成本优先空闲 30 分钟后睡眠 getSandbox(env.Sandbox, id, { sleepAfter: 30m, keepAlive: false }); // Always-on常驻不睡眠必须配套 destroy() getSandbox(env.Sandbox, id, { keepAlive: true });sleepAfter支持5m、1h、2d等时长字符串默认值10m睡眠中的沙箱会在下次请求时自动唤醒冷启动 23s。完整的参数语义见 configuration.md 的 getSandbox Options。高流量场景下还可以通过wrangler.jsonc提升并发实例上限// High traffic: increase max_instances { containers: [{ class_name: Sandbox, max_instances: 50 }] }四、安全最佳实践沙箱隔离每个沙箱 一个完全隔离的容器独立的文件系统、网络与进程命名空间多租户应用务必按租户使用唯一沙箱 ID防止跨租户状态串扰沙箱之间不能直接通信天然提供了网络级隔离边界。输入验证防御命令注入严禁将用户输入直接拼接到 shell 命令中执行——这是最典型的命令注入面// ❌ DANGEROUS: Command injection const result await sandbox.exec(python3 -c ${userCode}); // ✅ SAFE: Write to file, execute file await sandbox.writeFile(/workspace/user_code.py, userCode); const result await sandbox.exec(python3 /workspace/user_code.py);正确姿势是先写文件、再执行文件同时配合 patterns.md 的多租户模式 中按用户拆分会话与工作目录的做法进一步收敛攻击面。资源限制为长任务设置超时默认情况下exec()的超时上限为 120 秒但建议显式为可能失控的命令设置更短超时// Timeout long-running commands const result await sandbox.exec(python3 script.py, { timeout: 30000 // 30 seconds });密钥管理永不硬编码禁止在代码中硬编码 token一律通过wrangler secret put KEY注入环境变量再以env.GITHUB_TOKEN读取通过exec的env选项按需传给沙箱内的进程// ❌ NEVER hardcode secrets const token ghp_abc123; // ✅ Use environment secrets const token env.GITHUB_TOKEN; // Pass to sandbox via exec env const result await sandbox.exec(git clone ..., { env: { GIT_TOKEN: token } });预览 URL 安全预览 URL 内置自动生成的访问令牌形如https://8080-sandbox-abc123def456.yourdomain.com令牌在每次 expose 操作时都会变化从而防止历史链接被未授权复用。这也解释了为什么预览 URL 必须满足自定义域名 泛域名 DNS normalizeId: true 先调用proxyToSandbox()四项前提。五、资源规格、超时与性能边界实例类型规格ResourceLiteStandardHeavyRAM256MB512MB1GBvCPU0.512对应wrangler.jsonc中containers[].instance_type字段默认值为lite详见 configuration.md 的 Instance Types。如果任务超出heavy规格说明应当拆分任务或选用 containers 参考文档 中规格更高的容器实例。操作超时与覆盖方式OperationDefault TimeoutOverrideContainer provisioning容器供给30sSANDBOX_INSTANCE_TIMEOUT_MSPort readiness端口就绪90sSANDBOX_PORT_TIMEOUT_MSexec()120stimeoutoptionsleepAfter10msleepAfteroption前两项超时既可以在getSandbox的containerTimeouts选项中逐沙箱覆盖instanceGetTimeoutMS/portReadyTimeoutMS见 configuration.md也可以通过wrangler.jsonc的vars全局覆盖{ vars: { SANDBOX_INSTANCE_TIMEOUT_MS: 60000, // Override instanceGetTimeoutMS SANDBOX_PORT_TIMEOUT_MS: 120000 // Override portReadyTimeoutMS } }性能基线首次部署容器镜像构建约需 23 分钟冷启动从睡眠唤醒约 23 秒桶挂载仅生产环境可用本地wrangler dev无 FUSE 支持。六、生产部署要点正式上线前请务必确认以下事项已闭环生产部署指南入口见 gotchas.md 原文 指向的官方 Production Guide预览 URL 四项前提全部就绪自定义域名、泛域名 DNS、normalizeId: true、proxyToSandbox()最先调用生命周期可回收所有keepAlive: true的沙箱都有对应的destroy()路径持久化位置正确业务数据写入/workspace桶数据走mountBucket仅生产超时参数经过压测按实际供给与端口就绪耗时配置containerTimeouts与环境变量覆盖。七、核心规则速查从本文全部案例中可以提炼出 Cloudflare Sandbox 的七条铁律总是最先调用proxyToSandbox()预览 URL 的前提同 ID 复用沙箱不要用时间戳破坏 ID 的确定性持久文件放/workspace/tmp随时可能消失预览 URL 必须normalizeId: true且全局保持一致CONTAINER_NOT_READY要重试而不是报错返回keepAlive: true必须配destroy()否则容器永不释放用户代码先写文件再执行杜绝命令注入。如需查看这些规则对应的完整 API 与配置可继续阅读仓库内的 sandbox/README.md、sandbox/api.md、sandbox/configuration.md 与 sandbox/patterns.md涉及容器运行时底层机制如startAndWaitForPorts、WebSocket 代理、sleepAfter活动超时续期可对照 containers 参考文档 进一步深入。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考