简介本资源是针对XXL-JOB分布式任务调度平台的PostgreSQL数据库适配改造包面向Java后端开发工程师及中间件运维人员解决官方2.4.1版本仅原生支持MySQL、无法直接对接国产化或高可用PostgreSQL环境的落地难题。资源基于官方源码深度修改实现MySQL与PostgreSQL双库兼容通过配置文件动态切换附带两套完整建库建表SQL脚本开箱即用。压缩包共257个文件涵盖133个核心Java类含DAO层适配、JDBC方言增强、35个前端JS逻辑调度控制台交互、30个XML配置Spring Boot多数据源与MyBatis映射、12个CSS样式文件含AdminLTE、Layer、DataTables等主流UI组件整体体积仅1.8MB轻量且结构清晰。目前已有1402人学习下载读者可直接获取可编译运行的工程代码、双数据库部署方案、关键SQL语法迁移对照及前端调度界面兼容性优化细节显著降低企业级信创环境迁移成本。1. 这不是简单换驱动XXL-JOB 2.4.1 PostgreSQL 适配包解决的是分布式任务调度在国产化环境下的「启动即报错、建表就失败、调度不持久」三连击某公司信创改造项目上线前一周运维同学深夜发来截图XXL-JOB 执行器注册成功但调度中心首页空白日志里反复刷org.postgresql.util.PSQLException: ERROR: relation xxl_job_info does not exist。他们试过手动建表、改 schema、加 search_path全无效——因为官方 2.4.1 的 DDL 脚本压根没为 PostgreSQL 做语法兼容AUTO_INCREMENT、DATETIME(3)、TEXT类型默认值、索引写法全踩在 PG 的语法雷区上。这个适配包不是“换个 jdbc-url 就行”的玄学操作而是对xxl-job-admin模块的 SQL 初始化逻辑、MyBatis-Plus 实体映射、事务隔离级别、甚至 Quartz JDBCJobStore 配置做了深度手术。它让 XXL-JOB 真正在 PostgreSQL 12含国产达梦、人大金仓兼容模式上跑通全链路从初始化建库建表、UI 创建任务、触发执行、日志回传到失败重试与分片广播——所有状态都可查、可追溯、不丢不乱。适合正在做信创迁移、数据库国产化替代、或单纯被 MySQL 版本锁死想切 PG 的中后台开发和 DevOps 工程师。2. 项目结构与技术栈从源码包解压开始看清哪些文件动了、为什么必须动这个适配包不是打补丁而是基于 XXL-JOB 官方 2.4.1 Release 源码xxl-job-2.4.1-source.zip完整重构的可编译工程。你下载到的 zip 包里包含xxl-job-admin、xxl-job-core、xxl-job-executor-samples三个模块其中xxl-job-admin是核心改造区。整个适配围绕 PostgreSQL 的语义特性展开没有引入新框架纯靠调整 SQL、Mapper、配置与少量 Java 逻辑实现兼容。2.1 目录结构与关键变更文件清单解压后你会看到标准 Maven 多模块结构。重点盯住以下路径其他模块如core和executor-samples仅微调连接池配置未动业务逻辑xxl-job/ ├── xxl-job-admin/ │ ├── src/main/resources/ │ │ ├── application.properties ← 数据库驱动、URL、方言配置 │ │ ├── sql/ ← 全新重写的 PostgreSQL 初始化脚本 │ │ │ └── xxl_job_postgresql.sql ← 替代原 mysql.sql含建库、建表、索引、注释 │ │ └── mybatis-mapper/ ← MyBatis Mapper XML 文件 │ │ ├── XxlJobGroupMapper.xml ← 修复 PG 的 INSERT RETURNING 语法 │ │ ├── XxlJobInfoMapper.xml ← 修复时间字段类型映射与默认值 │ │ └── XxlJobLogMapper.xml ← 修复 BLOB 字段在 PG 中的处理转 bytea │ └── src/main/java/ │ └── com/xxl/job/admin/ │ └── dao/ ← DAO 层增强 │ ├── XxlJobGroupDao.java ← 新增 SelectKey 注解支持 PG 序列 │ └── XxlJobInfoDao.java ← 修复 save() 方法对 pgsql 的主键生成逻辑 └── pom.xml ← 升级 postgresql JDBC 驱动至 42.6.0提示sql/xxl_job_postgresql.sql是整个适配的基石。它不是简单把mysql.sql里的AUTO_INCREMENT换成SERIAL——PG 不支持DATETIME(3)得用TIMESTAMP WITH TIME ZONETEXT字段不能设默认值得用DEFAULT ::text唯一索引语法也得从UNIQUE KEY idx_abc (a,b,c)改成CREATE UNIQUE INDEX idx_abc ON xxl_job_info(a,b,c)。这些细节漏一条建表就失败。2.2 技术栈选型依据为什么是 PostgreSQL 12为什么不用 Flyway/Liquibase适配目标明确锁定 PostgreSQL 12 及以上含 13/14/15原因很实际12 原生支持GENERATED ALWAYS AS IDENTITY可替代SERIAL更符合 SQL 标准且 MyBatis-Plus 3.4 对其识别稳定12 的jsonb类型已成熟xxl_job_logglue表中glue_source字段从TEXT升级为jsonb便于后续做日志元数据检索比如查某次执行是否启用了 GLUE 模式放弃 Flyway/Liquibase 是血泪经验XXL-JOB 启动时强制校验表结构若引入外部迁移工具会与XxlJobAdminConfig.initAdmin()中的checkTable()逻辑冲突导致二次启动失败。所以选择「静态 SQL 启动时条件判断」——首次启动执行xxl_job_postgresql.sql非首次则跳过由application.properties中xxl.job.db.initfalse控制。2.3 核心依赖版本锁定JDBC 驱动与 MyBatis-Plus 的协同要点pom.xml中最关键的三处依赖变更!-- PostgreSQL JDBC Driver -- dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId version42.6.0/version !-- 必须 ≥42.3.0否则不支持 PreparedStatement.setObject(..., OffsetDateTime) -- /dependency !-- MyBatis-Plus 升级 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version !-- 修复 3.4.x 在 PG 下 LocalDateTime 映射为空的问题 -- /dependency !-- Quartz 适配 PG -- dependency groupIdorg.quartz-scheduler/groupId artifactIdquartz/artifactId version2.3.2/version !-- 官方 2.4.1 用的 2.3.2无需升级但需确认 quartz.properties 中 driverDelegateClass -- /dependency特别注意quartz.properties的关键配置项位于xxl-job-admin/src/main/resources/quartz.properties# 必须显式指定 PostgreSQL Delegate否则 Quartz 默认用 StdJDBCDelegate不兼容 PG 的序列和时间类型 org.quartz.jobStore.driverDelegateClass org.quartz.impl.jdbcjobstore.PostgreSQLDelegate # 关闭集群模式单实例部署时可省略但多节点必须开 org.quartz.jobStore.isClustered true # PG 的连接超时需加大避免长任务触发连接中断 org.quartz.dataSource.myDS.connectionProvider.class com.xxl.job.admin.core.conf.XxlJobPostgreDataSourceProviderXxlJobPostgreDataSourceProvider是新增类封装了 HikariCP 连接池对 PG 的socketTimeout、tcpKeepAlive、reWriteBatchedInsertstrue等参数的预设这是防止调度中心在高并发触发时出现Connection reset的关键。3. 运行前必做5 步初始化绕过 90% 的「启动失败」很多开发者卡在第一步java -jar xxl-job-admin.jar启动后页面打不开日志报Failed to initialize bean sqlSessionFactory。这不是代码问题是环境准备缺位。下面这 5 步我在线上环境反复验证过少一步都可能翻车。3.1 创建专用数据库与用户非 public schemaPostgreSQL 不像 MySQL 那样默认用 database 名当 schema。XXL-JOB 所有表必须建在明确指定的 schema 下推荐xxl_job否则 MyBatis-Plus 无法定位表。执行以下 SQL用postgres用户登录-- 创建专用 schema CREATE SCHEMA IF NOT EXISTS xxl_job; -- 创建专用用户生产环境严禁用 postgres 账号 CREATE USER xxl_job_user WITH PASSWORD StrongPass2024; -- 授权 GRANT ALL PRIVILEGES ON SCHEMA xxl_job TO xxl_job_user; GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA xxl_job TO xxl_job_user; GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA xxl_job TO xxl_job_user; -- 设置用户默认 schema关键否则 MyBatis 查不到表 ALTER USER xxl_job_user SET search_path TO xxl_job, public;注意search_path必须包含xxl_job且放在public前否则SELECT * FROM xxl_job_info会被解析成public.xxl_job_info而实际表在xxl_job下。3.2 手动执行初始化 SQL不要依赖 Spring Boot 自动建表Spring Boot 的spring.jpa.hibernate.ddl-autocreate在 PG 下不可靠尤其涉及jsonb和bytea字段。必须手动执行# 进入 PostgreSQL 容器或本地 psql psql -U xxl_job_user -d your_db_name -f xxl-job/xxl-job-admin/src/main/resources/sql/xxl_job_postgresql.sql该 SQL 文件已按顺序执行创建xxl_job_group、xxl_job_info、xxl_job_log等 10 张核心表为xxl_job_log的handle_code字段建部分索引WHERE handle_code ! 200加速失败日志查询为xxl_job_info的job_cron字段加注释COMMENT ON COLUMN xxl_job_info.job_cron IS Cron 表达式用于 Quartz 调度方便 DBA 理解。3.3 修改 application.properties 的四大关键项xxl-job-admin/src/main/resources/application.properties中以下四行必须按实情修改其余可保留默认### db spring.datasource.urljdbc:postgresql://127.0.0.1:5432/your_db_name?currentSchemaxxl_jobreWriteBatchedInsertstruesocketTimeout30 spring.datasource.usernamexxl_job_user spring.datasource.passwordStrongPass2024 # 必须显式声明方言否则 MyBatis-Plus 用 GenericDialect不识别 PG 的 RETURNING 语法 mybatis-plus.configuration.database-idpostgresql ### xxl-job # 关闭自动建表我们已手动执行 xxl.job.db.initfalse # 指定 Quartz 使用 PG Delegate见上文 org.quartz.jobStore.driverDelegateClassorg.quartz.impl.jdbcjobstore.PostgreSQLDelegate提示currentSchemaxxl_job是 URL 参数比search_path更精准确保连接一建立就绑定 schema避免跨 schema 查询歧义。3.4 编译与启动跳过 test指定 profile由于适配包未提供单元测试覆盖 PG 场景直接跳过测试编译cd xxl-job mvn clean package -Dmaven.test.skiptrue -pl xxl-job-admin -am # 输出 jar 在 xxl-job-admin/target/xxl-job-admin-2.4.1.jar java -jar xxl-job-admin-2.4.1.jar --spring.profiles.activeprod--spring.profiles.activeprod会加载application-prod.properties若存在其中可覆盖数据库密码等敏感配置避免硬编码在application.properties。3.5 验证启动成功的三大信号不要只看控制台Started Application in X seconds。真正成功需同时满足HTTP 端口监听netstat -tuln | grep 8080确认 8080 端口处于LISTEN状态Quartz 初始化日志日志中出现Initialized Scheduler Successfully且无Failed to obtain DB connection首条调度日志入库手动在 UI 创建一个「每分钟执行」的任务等待 1 分钟后执行然后查库SELECT trigger_time, handle_code, handle_msg FROM xxl_job_log WHERE job_id (SELECT id FROM xxl_job_info WHERE job_name test_job) ORDER BY trigger_time DESC LIMIT 1;若返回一行handle_code200说明从 Quartz 触发 → 执行器回调 → 日志落库 全链路打通。4. 常见问题排查5 条真实踩坑记录每条都来自线上故障复盘这类数据库适配项目80% 的问题出在环境细节。下面 5 条是我帮三个团队远程排障时高频遇到的按「现象 → 原因 → 解决」结构整理拒绝模糊描述。4.1 现象调度中心 UI 显示「无可用执行器」但执行器日志显示注册成功原因xxl_job_registry表的update_time字段类型为TIMESTAMP WITH TIME ZONE而执行器上报的心跳时间未带时区信息导致WHERE update_time NOW() - INTERVAL 30 seconds永远不成立。解决在XxlJobRegistryDao.java的findDead方法中将NOW()替换为CURRENT_TIMESTAMP AT TIME ZONE UTC并确保执行器 JVM 启动参数加入-Duser.timezoneGMT0。4.2 现象任务执行日志中glue_source字段为空但执行器控制台输出正常原因xxl_job_logglue表的glue_source原为TEXT适配后改为jsonb但 MyBatis-Plus 的TypeHandler未注册JsonbTypeHandler导致写入时被序列化为null。解决在MybatisPlusConfig.java中添加Bean public ConfigurationCustomizer configurationCustomizer() { return configuration - configuration.getTypeHandlerRegistry() .register(JsonbTypeHandler.class); }并新建JsonbTypeHandler.java继承BaseTypeHandlerJSONObject重写setNonNullParameter方法调用PGobject(jsonb, jsonStr)。4.3 现象分片广播任务只在一个执行器上运行其他执行器收不到分片参数原因XxlJobTrigger.java中的shardIndex计算逻辑依赖XxlJobGroup表的address_list字段而 PG 对字符串数组的解析string_to_array(address_list, ,)在ORDER BY子句中不稳定导致分片序号每次不同。解决将address_list字段类型从TEXT改为TEXT[]数组类型并在 DAO 层用Select(SELECT array_length(address_list, 1) FROM xxl_job_group WHERE app_name #{appName})获取长度再用 Java 侧Collections.sort()确保地址列表顺序固定。4.4 现象执行器频繁报Connection closed by foreign host调度中心日志出现大量Broken pipe原因PostgreSQL 服务端tcp_keepalives_idle默认 0禁用而 XXL-JOB 执行器长连接空闲超 5 分钟后被中间网络设备断开但客户端未感知。解决在application.properties的 JDBC URL 中追加tcpKeepAlivetruekeepAliveIdle300同时在 PostgreSQL 服务端postgresql.conf中设置tcp_keepalives_idle 300 tcp_keepalives_interval 60 tcp_keepalives_count 54.5 现象使用 GLUE 模式编辑 Groovy 脚本后保存再次打开内容变成乱码或截断原因xxl_job_glueregistry表的glue_source字段为jsonb但 Groovy 脚本含 Unicode 字符如中文注释JDBC 驱动未启用characterEncodingutf8。解决修正 JDBC URL必须显式声明编码spring.datasource.urljdbc:postgresql://...?currentSchemaxxl_jobcharacterEncodingutf8...并确认 PostgreSQL 服务端client_encoding为utf8SHOW client_encoding;。5. 核心模块拆解XxlJobInfoMapper.xml 与 XxlJobInfoDao.java 的 PG 适配逻辑真正理解这个适配包必须看懂它是如何让 MyBatis-Plus 在 PostgreSQL 下正确生成主键、插入时间、返回自增 ID 的。下面以XxlJobInfo任务信息表为例逐段拆解 XML 与 Java 的协同设计。5.1xxl_job_info表结构关键字段PostgreSQL 版先看xxl_job_postgresql.sql中建表语句的核心片段CREATE TABLE xxl_job_info ( id SERIAL PRIMARY KEY, job_group INT NOT NULL, job_cron VARCHAR(128) NOT NULL, job_desc VARCHAR(255) NOT NULL, add_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, update_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, author VARCHAR(64), alarm_email VARCHAR(255), executor_route_strategy VARCHAR(50), executor_handler VARCHAR(255), executor_param VARCHAR(512), executor_block_strategy VARCHAR(50), executor_timeout INT DEFAULT 0, executor_fail_retry_count INT DEFAULT 0, glue_type VARCHAR(50), glue_source TEXT, glue_remark VARCHAR(128), glue_updatetime TIMESTAMP WITH TIME ZONE, child_jobid VARCHAR(255), trigger_status SMALLINT DEFAULT 0, trigger_last_time BIGINT DEFAULT 0, trigger_next_time BIGINT DEFAULT 0 ); COMMENT ON COLUMN xxl_job_info.add_time IS 创建时间; COMMENT ON COLUMN xxl_job_info.glue_source IS GLUE 源码支持 Groovy、Java 等;注意三点主键id用SERIAL等价于INTEGER GENERATED BY DEFAULT AS IDENTITY非BIGINT因 XXL-JOB 任务量通常不超千万时间字段全为TIMESTAMP WITH TIME ZONE而非TIMESTAMP WITHOUT TIME ZONE确保跨时区部署时时间一致glue_source仍为TEXT非jsonb因 Groovy 脚本是纯文本jsonb会强制校验 JSON 格式反而限制灵活性。5.2XxlJobInfoMapper.xml中的 INSERT 语句含 RETURNINGMySQL 版本用useGeneratedKeystruekeyPropertyid即可。PG 必须用RETURNING子句且 MyBatis 不支持useGeneratedKeys与RETURNING共存。因此 XML 中这样写insert idsave parameterTypecom.xxl.job.admin.core.model.XxlJobInfo useGeneratedKeysfalse INSERT INTO xxl_job_info ( job_group, job_cron, job_desc, add_time, update_time, author, alarm_email, executor_route_strategy, executor_handler, executor_param, executor_block_strategy, executor_timeout, executor_fail_retry_count, glue_type, glue_source, glue_remark, glue_updatetime, child_jobid, trigger_status, trigger_last_time, trigger_next_time ) VALUES ( #{jobGroup}, #{jobCron}, #{jobDesc}, NOW(), NOW(), #{author}, #{alarmEmail}, #{executorRouteStrategy}, #{executorHandler}, #{executorParam}, #{executorBlockStrategy}, #{executorTimeout}, #{executorFailRetryCount}, #{glueType}, #{glueSource}, #{glueRemark}, NOW(), #{childJobid}, #{triggerStatus}, #{triggerLastTime}, #{triggerNextTime} ) RETURNING id /insert关键点useGeneratedKeysfalse是必须的否则 MyBatis 会忽略RETURNINGNOW()函数直接写在 SQL 中而非 Java 传参确保数据库服务端时间统一RETURNING id返回单列MyBatis 会自动将结果赋值给XxlJobInfo.id字段。5.3XxlJobInfoDao.java中的 save() 方法签名与调用DAO 接口方法定义看似普通但背后有隐式契约Mapper public interface XxlJobInfoDao { /** * 保存任务信息PostgreSQL 版依赖 RETURNING id * param info 任务对象id 字段将被 RETURNING 赋值 * return 影响行数总是 1 */ int save(XxlJobInfo info); // 其他方法... }调用方如XxlJobInfoController.java代码不变XxlJobInfo info new XxlJobInfo(); info.setJobGroup(1); info.setJobCron(0 * * * * ?); // 每分钟 // ... 设置其他字段 int ret xxlJobInfoDao.save(info); // 执行后info.getId() 已被赋值这就是 MyBatis 的魔法RETURNING结果自动映射回传入对象的id字段。不需要额外SELECT LASTVAL()也不需要SelectKey注解——那是旧版兼容写法此包已弃用。5.4XxlJobInfoMapper.xml中的 UPDATE 语句时间字段自动更新MySQL 用ON UPDATE CURRENT_TIMESTAMPPG 不支持。所以 UPDATE 语句中必须显式设置update_timeupdate idupdate parameterTypecom.xxl.job.admin.core.model.XxlJobInfo UPDATE xxl_job_info SET job_group #{jobGroup}, job_cron #{jobCron}, job_desc #{jobDesc}, update_time NOW(), !-- 关键每次更新都重置 -- author #{author}, alarm_email #{alarmEmail}, executor_route_strategy #{executorRouteStrategy}, executor_handler #{executorHandler}, executor_param #{executorParam}, executor_block_strategy #{executorBlockStrategy}, executor_timeout #{executorTimeout}, executor_fail_retry_count #{executorFailRetryCount}, glue_type #{glueType}, glue_source #{glueSource}, glue_remark #{glueRemark}, glue_updatetime #{glueUpdatetime}, child_jobid #{childJobid}, trigger_status #{triggerStatus}, trigger_last_time #{triggerLastTime}, trigger_next_time #{triggerNextTime} WHERE id #{id} /update提示update_time NOW()写在 SQL 层而非 Java 层setUpdateTime(new Date())是为了避免 JVM 时钟漂移导致时间不一致。所有时间戳均由数据库服务端生成这是分布式系统的基本原则。6. 二次开发指南如何安全地扩展「任务依赖」功能并兼容 PostgreSQL很多团队在用熟 XXL-JOB 后会提出「任务 A 执行完才触发任务 B」的需求。官方不支持 DAG但这个适配包的 PostgreSQL 基础让你能低成本实现。下面是以「增加xxl_job_dependency表 修改触发逻辑」为例的完整改造路径已在某金融客户生产环境稳定运行 8 个月。6.1 新增依赖关系表SQL 层在xxl_job_postgresql.sql末尾追加-- 任务依赖表task_id 依赖于 parent_idtype1 表示串行type2 表示并行 CREATE TABLE xxl_job_dependency ( id SERIAL PRIMARY KEY, task_id INT NOT NULL REFERENCES xxl_job_info(id) ON DELETE CASCADE, parent_id INT NOT NULL REFERENCES xxl_job_info(id) ON DELETE CASCADE, type SMALLINT DEFAULT 1 CHECK (type IN (1,2)), create_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, UNIQUE (task_id, parent_id) ); COMMENT ON TABLE xxl_job_dependency IS 任务依赖关系表; COMMENT ON COLUMN xxl_job_dependency.type IS 1: 串行依赖parent 成功后触发 task2: 并行依赖parent 成功后task 可立即执行;注意REFERENCES ... ON DELETE CASCADE是 PG 特性MySQL 8.0 才支持此处利用 PG 的外键级联删除避免任务删除后依赖关系残留。6.2 扩展 XxlJobInfo 实体类Java 层在XxlJobInfo.java中新增字段保持与数据库字段名一致// 新增依赖相关字段非数据库字段仅用于传输 private ListXxlJobDependency dependencies; // 该任务所依赖的父任务列表 private ListXxlJobDependency dependents; // 依赖该任务的子任务列表 // getter/setter 略同时新建XxlJobDependency.javapublic class XxlJobDependency { private Integer id; private Integer taskId; // 当前任务 ID private Integer parentId; // 父任务 ID private Integer type; // 1 串行2 并行 private Date createTime; // getter/setter 略 }6.3 修改触发逻辑核心在 XxlJobTrigger.trigger() 中注入依赖检查原逻辑在XxlJobTrigger.java的trigger()方法中直接调用scheduleThread.pushTriggerQueue()。现在需前置检查依赖// 在 trigger() 方法开头插入 if (jobInfo.getTriggerStatus() 1) { // 仅对启用状态的任务检查依赖 ListXxlJobDependency deps xxlJobDependencyDao.findByTaskId(jobInfo.getId()); if (!deps.isEmpty()) { boolean allParentsSuccess true; for (XxlJobDependency dep : deps) { // 查询父任务最近一次执行日志 XxlJobLog lastLog xxlJobLogDao.findLogLast(dep.getParentId()); if (lastLog null || lastLog.getHandleCode() ! 200) { allParentsSuccess false; break; } } if (!allParentsSuccess) { logger.info( xxl-job, skip trigger job[id{}], due to unmet dependency, jobInfo.getId()); return; } } } // 后续继续原有 trigger 逻辑...提示xxlJobLogDao.findLogLast()需在 DAO 层新增SQL 用SELECT * FROM xxl_job_log WHERE job_id ? ORDER BY trigger_time DESC LIMIT 1PG 的LIMIT 1性能极佳无需担心。6.4 验证与灰度上线策略新增功能绝不直接上线。我的做法是三步走离线验证用curl模拟触发请求观察日志是否打印skip trigger灰度开关在application.properties中加xxl.job.dependency.enabledtrue代码中用Value(${xxl.job.dependency.enabled:false})控制新任务默认不开启依赖监控埋点在XxlJobTrigger.trigger()中统计dependencyCheckSkipCount接入 Prometheus一旦跳过率突增立刻告警。从那以后我每次给 XXL-JOB 加新功能都强制走一遍「SQL 建表 → 实体扩展 → DAO 新增 → Service 注入 → 开关控制 → 监控埋点」这六步闭环。不是为了炫技而是因为分布式调度系统里一个没测透的依赖逻辑可能让整条资金流水线停摆两小时。希望帮到你。本文还有配套的精品资源点击获取