尧图网站建设 
简介这份资源是面向开发者与运维人员的N8N本地部署可运行源码包适合希望借助Docker快速搭建开源自动化工作流工具、并进一步研究其源码结构的技术爱好者。包内共4个文件以sh部署脚本、inscode配置、html介绍页面及gitignore忽略规则为主压缩包仅12KB轻量易取便于直接落地部署与二次开发。N8N支持Webhook、CRON作业、数据库操作、邮件与社交媒体等多类节点可通过拖放方式编排复杂自动化流程适用于企业内部流程自动化、IT运维与数据处理等场景。目前已有207人学习下载读者可参照脚本完成镜像拉取、容器运行与端口配置并结合源码理解其架构设计与运行机制为后续定制节点或集成自有服务打下基础。1. n8n 本地部署从 Docker 到源码一次把自动化工作流跑通如果你正在找一套能自己掌控数据、不依赖第三方云服务的自动化工具n8n 大概率已经出现在你的候选清单里。它把节点编排、API 调用、定时任务、条件分支这些能力揉进一个可视化画布同时保留了写 JavaScript 和 Python 的口子。问题在于官方托管版虽然省事但工作流里一旦涉及内部接口、数据库连接或者大模型调用数据出域就成了硬伤。本地部署 n8n 解决的正是这件事把编排引擎、凭证存储、执行日志全部放在你自己的机器上。这份可运行源码包适合两类人——想快速验证 n8n 能不能接进现有系统的后端工程师以及需要给团队搭一套私有自动化底座、但不想从零啃官方文档的运维同学。下面按实际拆包和跑通的顺序来。2. 部署方式选型Docker Compose 还是源码直跑2.1 两种路径的适用边界n8n 官方提供 npm 全局安装、Docker 镜像、以及从源码构建三种方式。源码包通常已经包含了docker-compose.yml、.env.example和若干初始化脚本所以实际落地时真正要决策的是用容器编排还是直接在宿主机跑 Node 进程。容器方案的优势在于环境隔离彻底PostgreSQL、Redis、n8n 主进程各自独立升级时替换镜像标签即可回滚也干净。缺点是文件挂载和网络模式需要额外配置尤其是工作流里要访问宿主机上的本地服务比如 Ollama 或内部 API时localhost在容器里指向的是容器自身必须换成host.docker.internal或宿主机局域网 IP。源码直跑的优势是调试方便改完节点代码重启进程就能生效适合要二次开发自定义节点的场景。代价是 Node 版本、依赖冲突、系统库缺失这些问题会直接暴露在宿主机上换一台机器复现时容易翻车。我一般会这样选如果只是跑现成工作流、接外部 API用 Docker Compose如果要改 n8n 核心代码或者写自定义节点包用源码方式但会在独立目录里用nvm锁死 Node 版本。2.2 Docker Compose 部署的完整操作源码包里的docker-compose.yml通常已经定义了 n8n 主服务和数据库。先看一份经过整理的配置version: 3.8 services: postgres: image: postgres:15 restart: unless-stopped environment: POSTGRES_USER: n8n POSTGRES_PASSWORD: n8n_password POSTGRES_DB: n8n volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U n8n] interval: 10s timeout: 5s retries: 5 n8n: image: n8nio/n8n:latest restart: unless-stopped ports: - 5678:5678 environment: - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDn8n_password - N8N_ENCRYPTION_KEYyour_encryption_key_here - N8N_HOSTlocalhost - N8N_PORT5678 - N8N_PROTOCOLhttp - WEBHOOK_URLhttp://localhost:5678/ - GENERIC_TIMEZONEAsia/Shanghai volumes: - n8n_data:/home/node/.n8n depends_on: postgres: condition: service_healthy volumes: postgres_data: n8n_data:这份配置里几个参数值得单独说。N8N_ENCRYPTION_KEY是凭证加密的根密钥一旦设定就不能随意更换否则之前存的所有 credentials 都会解密失败。WEBHOOK_URL决定了外部系统回调 n8n 时用的地址如果后面要接 GitHub Webhook 或者企业微信回调这里必须填外部可访问的域名或 IP不能写localhost。GENERIC_TIMEZONE影响 Cron 节点的触发时间不设的话默认 UTC定时任务会偏八小时。启动命令docker compose up -d docker compose logs -f n8n看到Editor is now accessible via: http://localhost:5678/就说明主进程起来了。第一次访问会要求设置 owner 账号这个账号只存在本地数据库里跟 n8n 官方云服务没有任何关系。2.3 源码直跑的依赖与启动如果源码包里没有 Docker 配置或者你明确要改代码走这条路。先确认 Node 版本n8n 对 Node 20 和 Node 22 的支持比较稳Node 18 在新版本里已经逐步弃用。# 用 nvm 锁定版本避免全局 Node 污染 nvm install 20 nvm use 20 # 安装 pnpmn8n 的 monorepo 用 pnpm 管理 npm install -g pnpm # 进入源码根目录 cd n8n-source # 安装依赖这一步耗时较长 pnpm install # 构建所有包 pnpm build # 启动主服务 pnpm startpnpm install阶段最常见的失败是node-gyp编译原生模块时报错通常是缺少python3和make、g。Ubuntu 下补一句apt install -y python3 make g就能过。pnpm build会编译前端和后端内存低于 4G 的机器可能被 OOM Killer 干掉加NODE_OPTIONS--max-old-space-size4096再跑。源码方式默认用 SQLite 存数据文件落在~/.n8n/database.sqlite。要换 PostgreSQL在启动前导出DB_TYPEpostgresdb和对应的连接变量即可跟 Docker 方案里的环境变量一致。3. 凭证管理与外部服务对接credentials 怎么配才不翻车3.1 credentials 的存储与加密逻辑n8n 里所有外部服务的密钥、Token、连接串都归在 credentials 里跟工作流节点解耦。这样做的好处是同一个数据库连接可以被多个工作流引用改一次密码全部生效。credentials 在数据库里是加密存储的加密用的就是前面提到的N8N_ENCRYPTION_KEY。这里有个血泪经验很多人第一次部署时随手填了个 key跑了一段时间后想迁移到另一台机器只导出了数据库文件没带 key结果所有凭证全部变成乱码。正确做法是把N8N_ENCRYPTION_KEY跟数据库备份放在一起或者用 Docker Secret、外部密钥管理服务单独存。3.2 对接本地大模型服务的配置示例现在很多工作流会调用本地跑的大模型比如通过 Ollama 暴露的接口。n8n 本身没有内置 Ollama 节点但可以用 HTTP Request 节点直接打。假设 Ollama 跑在宿主机11434端口n8n 跑在 Docker 里配置如下{ method: POST, url: http://host.docker.internal:11434/api/generate, authentication: none, sendBody: true, bodyParameters: { model: qwen2.5:7b, prompt: {{ $json.user_input }}, stream: false }, options: { timeout: 120000 } }关键点在host.docker.internal这个主机名。Linux 下 Docker 默认不解析它需要在docker-compose.yml的 n8n 服务里加一行extra_hosts: - host.docker.internal:host-gateway。不加的话请求会直接超时日志里只看到ECONNREFUSED容易误判成 Ollama 没启动。timeout设成 120 秒是因为本地 7B 模型首次加载要几十秒默认超时太短会中断。如果模型常驻显存可以降到 30 秒。3.3 数据库凭证与连接测试接 PostgreSQL 或 MySQL 时n8n 的数据库节点支持两种模式用 credentials 里的连接配置或者在节点里直接写连接串。推荐用 credentials原因是连接串写在节点里会随工作流导出而泄露。配置完 credentials 后界面上有个Test按钮。这个测试走的是 n8n 后端进程的网络栈如果 n8n 在容器里、数据库在宿主机测试失败但实际工作流能跑的情况也存在——因为测试可能用了不同的解析路径。遇到测试失败先别急着改配置直接建一个最小工作流用数据库节点执行SELECT 1以实际执行结果为准。4. 工作流导入导出与版本迁移的排查清单4.1 工作流 JSON 的结构与导入注意n8n 的工作流导出是一个 JSON 文件里面包含节点定义、连接关系、位置坐标和凭证引用。凭证引用只存 ID 和名称不存实际密钥所以跨实例导入时凭证需要重新绑定。导入时最常见的现象是节点显示红色感叹号提示Credentials not found。原因不是导入失败而是目标实例里没有同名同类型的凭证。解决办法是先在新实例里建好凭证再导入工作流然后在每个报错节点上手动选择对应凭证。节点多的时候很烦但这是加密机制决定的没有后悔药。4.2 版本升级时的数据库迁移n8n 升级大版本时启动过程会自动跑数据库迁移。如果迁移失败主进程会退出日志里能看到Migration failed和具体的 SQL 错误。这时候不要反复重启先把数据库备份出来再看迁移脚本卡在哪一步。一个实际踩过的坑从某个旧版本升到新版本时credentials_entity表里存在重复的name字段新版本加了唯一约束迁移直接报冲突。解决方式是先手动删掉重复记录再重新启动。这类问题在跨大版本升级时概率不低所以升级前pg_dump一份是必须的。4.3 常见问题排查现象一访问 5678 端口显示连接被拒绝。原因通常是容器没起来或者端口没映射。先docker compose ps看状态如果是Exit状态docker compose logs n8n看退出原因。常见的是数据库连不上导致主进程启动失败。 解决确认 postgres 容器健康检查通过再重启 n8n 容器。现象二工作流执行到 HTTP 节点报ETIMEDOUT。原因是容器内 DNS 解析或网络出口有问题也可能是目标服务只监听127.0.0.1容器访问不到。 解决把目标服务改成监听0.0.0.0或者用host.docker.internal加extra_hosts配置。现象三Cron 节点设定的时间到了但不触发。原因是GENERIC_TIMEZONE没设或者设错n8n 按 UTC 算时间。 解决在环境变量里显式设成Asia/Shanghai重启后重新保存一次工作流让触发器重新注册。现象四导入工作流后所有节点位置重叠。原因是导出的 JSON 里position字段丢失或格式不对常见于手动改过 JSON 的情况。 解决重新从正常实例导出不要手工拼接节点数组。现象五执行日志里中文乱码。原因是数据库字符集不是 UTF-8或者容器 locale 没配。 解决PostgreSQL 建库时指定ENCODING UTF8Docker 环境里加LANGC.UTF-8。5. 进阶用环境变量控制执行行为与资源上限5.1 执行超时与并发控制n8n 默认对单个工作流执行有超时限制长任务容易被掐断。相关变量是EXECUTIONS_TIMEOUT和EXECUTIONS_TIMEOUT_MAX单位秒。设成-1表示不限制但生产环境不建议容易堆积僵尸执行。并发方面N8N_CONCURRENCY_PRODUCTION_LIMIT控制生产模式下同时执行的工作流数量。默认值比较保守机器配置好的话可以调高但要注意数据库连接池上限调太高会把 PostgreSQL 连接打满。# 在 docker-compose.yml 的 n8n 服务 environment 里追加 - EXECUTIONS_TIMEOUT300 - EXECUTIONS_TIMEOUT_MAX600 - N8N_CONCURRENCY_PRODUCTION_LIMIT10 - N8N_PAYLOAD_SIZE_MAX64N8N_PAYLOAD_SIZE_MAX单位是 MB默认 16。如果工作流要传大文件或者长文本不改这个会直接报Payload too large。5.2 用二进制数据节点处理文件流n8n 处理文件时二进制数据默认存在内存里。大文件场景下要开启N8N_DEFAULT_BINARY_DATA_MODEfilesystem让二进制落到磁盘临时目录避免内存爆掉。这个变量在 1.x 版本里行为有调整设完之后要实际跑一个读大文件的工作流验证看临时目录里有没有生成文件。5.3 验证部署是否真正可用部署完别只看界面能打开。建一个最小工作流手动触发 → HTTP Request 请求一个外部接口 → 把结果写回一个本地文件。跑通这条链路说明网络出口、节点执行、文件系统挂载都没问题。然后再建一个 Cron 触发的工作流等一个触发周期确认定时器生效。这两步走完才算真正部署完成。从那以后我每次部署完 n8n都会先跑一遍这个最小链路再动任何业务工作流。希望帮到你。本文还有配套的精品资源点击获取 n8n本地部署实战：Docker与源码双路径自动化工作流指南
简介这份资源是面向开发者与运维人员的N8N本地部署可运行源码包适合希望借助Docker快速搭建开源自动化工作流工具、并进一步研究其源码结构的技术爱好者。包内共4个文件以sh部署脚本、inscode配置、html介绍页面及gitignore忽略规则为主压缩包仅12KB轻量易取便于直接落地部署与二次开发。N8N支持Webhook、CRON作业、数据库操作、邮件与社交媒体等多类节点可通过拖放方式编排复杂自动化流程适用于企业内部流程自动化、IT运维与数据处理等场景。目前已有207人学习下载读者可参照脚本完成镜像拉取、容器运行与端口配置并结合源码理解其架构设计与运行机制为后续定制节点或集成自有服务打下基础。1. n8n 本地部署从 Docker 到源码一次把自动化工作流跑通如果你正在找一套能自己掌控数据、不依赖第三方云服务的自动化工具n8n 大概率已经出现在你的候选清单里。它把节点编排、API 调用、定时任务、条件分支这些能力揉进一个可视化画布同时保留了写 JavaScript 和 Python 的口子。问题在于官方托管版虽然省事但工作流里一旦涉及内部接口、数据库连接或者大模型调用数据出域就成了硬伤。本地部署 n8n 解决的正是这件事把编排引擎、凭证存储、执行日志全部放在你自己的机器上。这份可运行源码包适合两类人——想快速验证 n8n 能不能接进现有系统的后端工程师以及需要给团队搭一套私有自动化底座、但不想从零啃官方文档的运维同学。下面按实际拆包和跑通的顺序来。2. 部署方式选型Docker Compose 还是源码直跑2.1 两种路径的适用边界n8n 官方提供 npm 全局安装、Docker 镜像、以及从源码构建三种方式。源码包通常已经包含了docker-compose.yml、.env.example和若干初始化脚本所以实际落地时真正要决策的是用容器编排还是直接在宿主机跑 Node 进程。容器方案的优势在于环境隔离彻底PostgreSQL、Redis、n8n 主进程各自独立升级时替换镜像标签即可回滚也干净。缺点是文件挂载和网络模式需要额外配置尤其是工作流里要访问宿主机上的本地服务比如 Ollama 或内部 API时localhost在容器里指向的是容器自身必须换成host.docker.internal或宿主机局域网 IP。源码直跑的优势是调试方便改完节点代码重启进程就能生效适合要二次开发自定义节点的场景。代价是 Node 版本、依赖冲突、系统库缺失这些问题会直接暴露在宿主机上换一台机器复现时容易翻车。我一般会这样选如果只是跑现成工作流、接外部 API用 Docker Compose如果要改 n8n 核心代码或者写自定义节点包用源码方式但会在独立目录里用nvm锁死 Node 版本。2.2 Docker Compose 部署的完整操作源码包里的docker-compose.yml通常已经定义了 n8n 主服务和数据库。先看一份经过整理的配置version: 3.8 services: postgres: image: postgres:15 restart: unless-stopped environment: POSTGRES_USER: n8n POSTGRES_PASSWORD: n8n_password POSTGRES_DB: n8n volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U n8n] interval: 10s timeout: 5s retries: 5 n8n: image: n8nio/n8n:latest restart: unless-stopped ports: - 5678:5678 environment: - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDn8n_password - N8N_ENCRYPTION_KEYyour_encryption_key_here - N8N_HOSTlocalhost - N8N_PORT5678 - N8N_PROTOCOLhttp - WEBHOOK_URLhttp://localhost:5678/ - GENERIC_TIMEZONEAsia/Shanghai volumes: - n8n_data:/home/node/.n8n depends_on: postgres: condition: service_healthy volumes: postgres_data: n8n_data:这份配置里几个参数值得单独说。N8N_ENCRYPTION_KEY是凭证加密的根密钥一旦设定就不能随意更换否则之前存的所有 credentials 都会解密失败。WEBHOOK_URL决定了外部系统回调 n8n 时用的地址如果后面要接 GitHub Webhook 或者企业微信回调这里必须填外部可访问的域名或 IP不能写localhost。GENERIC_TIMEZONE影响 Cron 节点的触发时间不设的话默认 UTC定时任务会偏八小时。启动命令docker compose up -d docker compose logs -f n8n看到Editor is now accessible via: http://localhost:5678/就说明主进程起来了。第一次访问会要求设置 owner 账号这个账号只存在本地数据库里跟 n8n 官方云服务没有任何关系。2.3 源码直跑的依赖与启动如果源码包里没有 Docker 配置或者你明确要改代码走这条路。先确认 Node 版本n8n 对 Node 20 和 Node 22 的支持比较稳Node 18 在新版本里已经逐步弃用。# 用 nvm 锁定版本避免全局 Node 污染 nvm install 20 nvm use 20 # 安装 pnpmn8n 的 monorepo 用 pnpm 管理 npm install -g pnpm # 进入源码根目录 cd n8n-source # 安装依赖这一步耗时较长 pnpm install # 构建所有包 pnpm build # 启动主服务 pnpm startpnpm install阶段最常见的失败是node-gyp编译原生模块时报错通常是缺少python3和make、g。Ubuntu 下补一句apt install -y python3 make g就能过。pnpm build会编译前端和后端内存低于 4G 的机器可能被 OOM Killer 干掉加NODE_OPTIONS--max-old-space-size4096再跑。源码方式默认用 SQLite 存数据文件落在~/.n8n/database.sqlite。要换 PostgreSQL在启动前导出DB_TYPEpostgresdb和对应的连接变量即可跟 Docker 方案里的环境变量一致。3. 凭证管理与外部服务对接credentials 怎么配才不翻车3.1 credentials 的存储与加密逻辑n8n 里所有外部服务的密钥、Token、连接串都归在 credentials 里跟工作流节点解耦。这样做的好处是同一个数据库连接可以被多个工作流引用改一次密码全部生效。credentials 在数据库里是加密存储的加密用的就是前面提到的N8N_ENCRYPTION_KEY。这里有个血泪经验很多人第一次部署时随手填了个 key跑了一段时间后想迁移到另一台机器只导出了数据库文件没带 key结果所有凭证全部变成乱码。正确做法是把N8N_ENCRYPTION_KEY跟数据库备份放在一起或者用 Docker Secret、外部密钥管理服务单独存。3.2 对接本地大模型服务的配置示例现在很多工作流会调用本地跑的大模型比如通过 Ollama 暴露的接口。n8n 本身没有内置 Ollama 节点但可以用 HTTP Request 节点直接打。假设 Ollama 跑在宿主机11434端口n8n 跑在 Docker 里配置如下{ method: POST, url: http://host.docker.internal:11434/api/generate, authentication: none, sendBody: true, bodyParameters: { model: qwen2.5:7b, prompt: {{ $json.user_input }}, stream: false }, options: { timeout: 120000 } }关键点在host.docker.internal这个主机名。Linux 下 Docker 默认不解析它需要在docker-compose.yml的 n8n 服务里加一行extra_hosts: - host.docker.internal:host-gateway。不加的话请求会直接超时日志里只看到ECONNREFUSED容易误判成 Ollama 没启动。timeout设成 120 秒是因为本地 7B 模型首次加载要几十秒默认超时太短会中断。如果模型常驻显存可以降到 30 秒。3.3 数据库凭证与连接测试接 PostgreSQL 或 MySQL 时n8n 的数据库节点支持两种模式用 credentials 里的连接配置或者在节点里直接写连接串。推荐用 credentials原因是连接串写在节点里会随工作流导出而泄露。配置完 credentials 后界面上有个Test按钮。这个测试走的是 n8n 后端进程的网络栈如果 n8n 在容器里、数据库在宿主机测试失败但实际工作流能跑的情况也存在——因为测试可能用了不同的解析路径。遇到测试失败先别急着改配置直接建一个最小工作流用数据库节点执行SELECT 1以实际执行结果为准。4. 工作流导入导出与版本迁移的排查清单4.1 工作流 JSON 的结构与导入注意n8n 的工作流导出是一个 JSON 文件里面包含节点定义、连接关系、位置坐标和凭证引用。凭证引用只存 ID 和名称不存实际密钥所以跨实例导入时凭证需要重新绑定。导入时最常见的现象是节点显示红色感叹号提示Credentials not found。原因不是导入失败而是目标实例里没有同名同类型的凭证。解决办法是先在新实例里建好凭证再导入工作流然后在每个报错节点上手动选择对应凭证。节点多的时候很烦但这是加密机制决定的没有后悔药。4.2 版本升级时的数据库迁移n8n 升级大版本时启动过程会自动跑数据库迁移。如果迁移失败主进程会退出日志里能看到Migration failed和具体的 SQL 错误。这时候不要反复重启先把数据库备份出来再看迁移脚本卡在哪一步。一个实际踩过的坑从某个旧版本升到新版本时credentials_entity表里存在重复的name字段新版本加了唯一约束迁移直接报冲突。解决方式是先手动删掉重复记录再重新启动。这类问题在跨大版本升级时概率不低所以升级前pg_dump一份是必须的。4.3 常见问题排查现象一访问 5678 端口显示连接被拒绝。原因通常是容器没起来或者端口没映射。先docker compose ps看状态如果是Exit状态docker compose logs n8n看退出原因。常见的是数据库连不上导致主进程启动失败。 解决确认 postgres 容器健康检查通过再重启 n8n 容器。现象二工作流执行到 HTTP 节点报ETIMEDOUT。原因是容器内 DNS 解析或网络出口有问题也可能是目标服务只监听127.0.0.1容器访问不到。 解决把目标服务改成监听0.0.0.0或者用host.docker.internal加extra_hosts配置。现象三Cron 节点设定的时间到了但不触发。原因是GENERIC_TIMEZONE没设或者设错n8n 按 UTC 算时间。 解决在环境变量里显式设成Asia/Shanghai重启后重新保存一次工作流让触发器重新注册。现象四导入工作流后所有节点位置重叠。原因是导出的 JSON 里position字段丢失或格式不对常见于手动改过 JSON 的情况。 解决重新从正常实例导出不要手工拼接节点数组。现象五执行日志里中文乱码。原因是数据库字符集不是 UTF-8或者容器 locale 没配。 解决PostgreSQL 建库时指定ENCODING UTF8Docker 环境里加LANGC.UTF-8。5. 进阶用环境变量控制执行行为与资源上限5.1 执行超时与并发控制n8n 默认对单个工作流执行有超时限制长任务容易被掐断。相关变量是EXECUTIONS_TIMEOUT和EXECUTIONS_TIMEOUT_MAX单位秒。设成-1表示不限制但生产环境不建议容易堆积僵尸执行。并发方面N8N_CONCURRENCY_PRODUCTION_LIMIT控制生产模式下同时执行的工作流数量。默认值比较保守机器配置好的话可以调高但要注意数据库连接池上限调太高会把 PostgreSQL 连接打满。# 在 docker-compose.yml 的 n8n 服务 environment 里追加 - EXECUTIONS_TIMEOUT300 - EXECUTIONS_TIMEOUT_MAX600 - N8N_CONCURRENCY_PRODUCTION_LIMIT10 - N8N_PAYLOAD_SIZE_MAX64N8N_PAYLOAD_SIZE_MAX单位是 MB默认 16。如果工作流要传大文件或者长文本不改这个会直接报Payload too large。5.2 用二进制数据节点处理文件流n8n 处理文件时二进制数据默认存在内存里。大文件场景下要开启N8N_DEFAULT_BINARY_DATA_MODEfilesystem让二进制落到磁盘临时目录避免内存爆掉。这个变量在 1.x 版本里行为有调整设完之后要实际跑一个读大文件的工作流验证看临时目录里有没有生成文件。5.3 验证部署是否真正可用部署完别只看界面能打开。建一个最小工作流手动触发 → HTTP Request 请求一个外部接口 → 把结果写回一个本地文件。跑通这条链路说明网络出口、节点执行、文件系统挂载都没问题。然后再建一个 Cron 触发的工作流等一个触发周期确认定时器生效。这两步走完才算真正部署完成。从那以后我每次部署完 n8n都会先跑一遍这个最小链路再动任何业务工作流。希望帮到你。本文还有配套的精品资源点击获取