简介：Oracle 19c TZ41 补丁（P35099667-190000-MSWIN-x86-64）面向 Windows 2008 及以上环境下维护 Oracle 19c 的数据库管理员与运维人员，主要用于更新时区数据，并规避与时间区域相关的性能、安全和稳定性问题，适合跨时区业务、补丁核对及日常巡检场景。压缩包共 10 个文件，大小约 352KB，以 6 个 dat 数据文件为主，辅以 2 个 xml 配置文件和 2 个 txt 说明文档，便于识别补丁内容、阅读说明并核对配置项。已有 712 人学习，说明该补丁在 Windows 平台 Oracle 维护中具有实际参考需求。读者可获得 TZ41 时区更新所需的文件集合、说明材料与配置依据，用于应用前的内容确认、版本比对和问题排查，降低因时区规则不一致造成的报表偏差与运行风险。

1. Oracle 19c TZ41 补丁 p35099667 在 Windows 上安装，别被 zip 后缀骗了

Oracle 19c TZ41 补丁 p35099667-190000-MSWIN-x86-64.zip 拿到手时，很多人第一反应是双击解压、找 setup，结果发现里面没有安装程序。这不是普通的 Windows 安装包，而是给 Oracle 19c Windows x86-64 用的时区补丁，ORACLETZ41 对应的就是这一类时区文件更新。装不好不会立刻报错，可能会在跨时区业务、日期计算、数据泵导入时突然翻车。下面按我实际装库的顺序，从版本核对、OPatch 预检、apply、datapatch 到验证，一步步走。

2. 装前核对：Oracle 19c Windows x86-64 的版本、OPatch 和 p35099667 补丁边界

2.1 先确认实例版本与时区文件：TZ41 不是随便哪个 19c 都能套

补丁文件名里的190000和MSWIN-x86-64不是装饰。前者对应 19c 基线，后者说明这是 Windows 64 位平台补丁，拿到 Linux 的 Oracle Home 里执行opatch apply只会得到一句不适用。TZ41 也不是“装完就多一个功能”的普通补丁，它更新的是数据库时区文件，影响TIMESTAMP WITH TIME ZONE、跨时区转换、数据泵和部分日期函数的结果。

我一般在装之前先连进实例，把版本、时区文件和已经打过的 SQL 补丁查一遍。不要只看sqlplus -v，那只说明客户端版本；要进库查v$instance和v$timezone_file。如果时区文件已经是 41，先确认是不是同一补丁已经装过，不要重复执行。查询命令如下：

-- 以 sysdba 身份登录后执行，先确认实例版本和时区文件版本 set pagesize 200 linesize 200 select banner_full from v$version; select version_full from v$instance; select * from v$timezone_file; -- 查最近打过的 SQL 补丁，确认 35099667 是否已经注册 select patch_id, patch_type, action, status, description, action_time from dba_registry_sqlpatch order by action_time desc;

banner_full能看到 19c 的具体版本，version_full用来确认当前实例和 ORACLE_HOME 对得上。v$timezone_file里重点看VERSION，TZ41 装完后这里应该落到 41；如果还是旧值，说明补丁文件进了 Oracle Home，但数据库时区数据没有完成升级。dba_registry_sqlpatch用来判断这个补丁是否已经注册过，避免在同一个库上重复跑datapatch。

这里有一个容易忽略的边界：单实例和 CDB/PDB 的检查方式不完全一样。CDB 里要在根容器确认 SQL 补丁注册情况，PDB 要确认是否处于 READ WRITE 且已经打开。如果 PDB 没开，datapatch可能只处理了部分容器，后面查dba_registry_sqlpatch就会看到记录不完整。常见做法是先show pdbs，把需要处理的 PDB 全部打开，再执行补丁后的 SQL 注册。

注意：如果v$timezone_file已经是 41，而dba_registry_sqlpatch里没有 35099667，不要急着判断“补丁不用装”。先看是不是之前用别的补丁号更新过时区文件，再对照补丁 README 的冲突说明处理。

2.2 OPatch 检查：Windows 下 opatch.bat 的路径和 Java

Windows 上装 Oracle 补丁，真正干活的不是安装向导，而是%ORACLE_HOME%\OPatch\opatch.bat。很多人卡在第一步：在普通 cmd 里直接敲opatch，系统提示找不到命令。原因不是 OPatch 没装，而是 PATH 里没有%ORACLE_HOME%\OPatch，或者当前窗口没有设置ORACLE_HOME。我习惯先开一个管理员 cmd，把环境变量固定下来，再执行版本检查和 inventory 备份。

-- 以管理员身份打开 cmd，先固定 ORACLE_HOME 和 ORACLE_SID set ORACLE_HOME=D:\app\oracle\product\19.0.0\dbhome_1 set ORACLE_SID=ORCL set PATH=%ORACLE_HOME%\bin;%ORACLE_HOME%\OPatch;%PATH% -- 确认 OPatch 能启动，并记录当前补丁清单 cd /d %ORACLE_HOME%\OPatch opatch.bat version opatch.bat lsinventory -detail > C:\patch_tmp\before_lsinventory.txt

ORACLE_HOME必须指向当前实例实际使用的 Oracle Home，不是客户端目录。ORACLE_SID要和OracleServiceORCL里的实例名一致，否则后面datapatch可能连到另一个库。opatch.bat version能正常输出，说明 OPatch 自身和 Java 环境基本可用；lsinventory -detail输出到文件，是为了出问题时能对比安装前后差异，也是回滚时的后悔药。

Windows 上还有一个坑：不要随手把系统JAVA_HOME指到某个新版本 JDK，然后指望 OPatch 跟着用。Oracle 的 OPatch 通常认自己目录下的运行时，或者认 Oracle Home 里的 Java 环境。系统 Java 改乱了，opatch.bat可能一启动就报找不到类。我的做法是只检查 OPatch 能不能跑，不改全局 Java 变量；如果确实报 Java 相关错误，先看%ORACLE_HOME%\OPatch下的日志和 README 要求，再决定是否按补丁说明更新 OPatch。

如果opatch.bat version输出了版本，但补丁 README 里写的最低 OPatch 版本更高，不要硬装。先按补丁包自带的说明升级 OPatch，再回到prereq检查。OPatch 版本不够时，apply有时不会在第一步报错，而是走到一半提示补丁不适用，那个时候 Oracle Home 里可能已经写入了部分文件，处理起来更麻烦。

2.3 停库与备份：先停监听还是先停实例

补丁安装期间最怕文件被占用。Windows 上 Oracle 的进程不像 Linux 那样容易看出来，服务没停净，opatch apply可能在中途报文件无法替换。我的顺序是：先通知应用断连接，停 EM 或 dbconsole（如果开了），停监听，再关实例；不要直接去任务管理器结束oracle.exe。结束进程看似快，后面起库时可能留下需要恢复的实例。

-- 先停监听，减少新连接进入 lsnrctl stop -- 再关实例，确保数据文件和控制文件正常关闭 sqlplus / as sysdba SQL> shutdown immediate SQL> exit -- 如果实例以 Windows 服务方式运行，确认服务状态 sc query OracleServiceORCL sc query OracleTNSListener

lsnrctl stop只停监听，不会关实例；shutdown immediate会回滚未提交事务并正常关闭实例。服务名在不同环境里可能是OracleServiceORCL、OracleTNSListener，也可能带 Oracle Home 前缀，先用sc query state= all | findstr /i "OracleService OracleTNSListener"查清楚再停。补丁安装前至少做两件事：数据库有可用备份，lsinventory有安装前快照。生产库不要省这一步，时区补丁回退比普通补丁更绕。

-- 安装前把 OPatch 清单和关键目录信息留档 mkdir C:\backup\before_tz41 opatch.bat lsinventory -detail > C:\backup\before_tz41\lsinventory_before.txt dir /s %ORACLE_HOME%\OPatch > C:\backup\before_tz41\opatch_dir.txt

lsinventory_before.txt用来对比补丁安装前后多了哪些 patch，opatch_dir.txt在 OPatch 自身出问题时能快速看目录结构。数据库备份按现有策略走，RMAN 也好，存储快照也好，关键是确认可恢复。补丁装坏了还有机会退，时区数据改错了再想回退，成本会高很多。

3. 解压与预检：p35099667 补丁目录、README 和 opatch prereq 怎么跑

3.1 解压到短路径：给 OPatch 一个不带空格和中文的目录

补丁 zip 不要放在桌面，也不要解压到带中文、带空格的路径。OPatch 对路径的处理没有想象中宽容，路径里空格多了，某些参数会被截断，最后报“补丁位置无效”。我一般固定用C:\patch_tmp这种短路径，先建目录，再用 PowerShell 解压。解压后要确认目录层级：真正给opatch apply用的目录里应该能看到etc、files这类子目录，而不是只有一层 zip 文件名。

# 以管理员身份打开 PowerShell，建立短路径并解压补丁 New-Item -ItemType Directory -Force -Path C:\patch_tmp\35099667 | Out-Null Expand-Archive -Path "C:\patch_tmp\p35099667-190000-MSWIN-x86-64.zip" ` -DestinationPath "C:\patch_tmp\35099667" -Force # 查看解压后的目录层级，确认补丁根目录 Get-ChildItem C:\patch_tmp\35099667

Expand-Archive的-DestinationPath指向临时目录，-Force用于覆盖旧解压结果。解压完不要急着opatch apply，先用Get-ChildItem或dir看目录。如果看到的是C:\patch_tmp\35099667\35099667\etc，说明补丁根目录多了一层，后面-phBaseDir和apply都要指到里层；如果直接看到etc，就指外层。这个层级判断错，是后面“不是有效补丁位置”的常见来源。

解压后的目录权限也要看一下。如果当前用户对C:\patch_tmp没有写权限，OPatch 在解压日志或临时文件时可能失败。把补丁目录放在系统盘根目录下通常没问题，但不要放在只读共享盘或同步盘里。同步盘在补丁安装期间可能锁定文件，导致 OPatch 读写 inventory 时出现异常。

3.2 读 README 的三处：OPatch 版本、冲突补丁、时区升级

补丁目录里的 README 不是摆设。TZ41 这种时区补丁，README 里至少有三处要确认：OPatch 最低版本、冲突补丁列表、安装后是否必须执行时区升级脚本。不同补丁包的 README 格式不完全一样，有的叫README.html，有的还有README.txt。先看文件列表，再打开对应文件，不要凭经验跳过。

-- 查看补丁目录里的说明文件和关键子目录 dir /b C:\patch_tmp\35099667\35099667 dir /b C:\patch_tmp\35099667\35099667\etc

dir /b只列文件名，方便确认 README 和etc是否存在。etc目录里通常放补丁元数据，files目录里是要替换或新增的文件。README 里的 OPatch 版本要求要和opatch.bat version的输出对比；冲突补丁要拿lsinventory里的 patch 列表对照；时区升级部分要确认是datapatch自动处理，还是需要单独跑utltz_upg_check.sql和utltz_upg_apply.sql。

我一般把 README 里的关键信息抄到安装记录里，至少留四项：补丁号、适用平台、OPatch 要求、安装后动作。这样后面datapatch报错时，能快速判断是补丁本身的问题，还是漏了某个后置步骤。补丁包里的说明和当前库的实际情况冲突时，以补丁 README 和当前 Oracle Home 的lsinventory为准，不要拿别的库的经验硬套。

注意：README 里的“Post-installation”部分要逐条看。时区补丁经常要求数据库重启，甚至要求先进入升级模式执行脚本；漏掉这一步，opatch lspatches能看到补丁号，但v$timezone_file仍然是旧版本。

3.3 opatch prereq 与报告模式：先把“能不能装”验证掉

正式apply之前，先跑prereq CheckApplicable和apply -report。前者检查补丁是否适用于当前 Oracle Home，后者模拟应用过程但不真正改文件。很多人省掉预检，直接apply，结果在交互提示里看到一堆冲突才回头查，时间成本更高。预检命令要在%ORACLE_HOME%\OPatch目录下执行，补丁路径指向含etc的那一层。

cd /d %ORACLE_HOME%\OPatch -- 检查补丁是否适用于当前 Oracle Home opatch.bat prereq CheckApplicable -phBaseDir C:\patch_tmp\35099667\35099667 -- 检查补丁与当前 Oracle Home 的冲突详情 opatch.bat prereq CheckConflictAgainstOHWithDetail -phBaseDir C:\patch_tmp\35099667\35099667 -- 报告模式跑一遍，不改文件，只看过程 opatch.bat apply C:\patch_tmp\35099667\35099667 -report

CheckApplicable通过，说明补丁平台和 Oracle Home 基本匹配；CheckConflictAgainstOHWithDetail用来发现已安装补丁冲突；apply -report会走一遍应用流程，输出将要执行的动作，但不会真正写入。预检报错时不要硬上，先把错误日志里的补丁号和路径抄出来，对照 README 和lsinventory查。预检通过后再做正式安装，心里会踏实很多。

如果-report阶段提示某些文件将被覆盖，先确认这些文件是否被其他补丁改过。Windows 上 Oracle Home 里有些文件会被多个补丁共享，冲突不一定代表不能装，但需要按 README 的冲突处理顺序来。我的习惯是：预检输出全部留档，正式 apply 的输出也重定向到文件，后面出问题能对比两次输出差异。

4. 正式安装：opatch apply、datapatch 和时区脚本的执行顺序

4.1 管理员 cmd 执行 opatch apply，别在资源管理器里双击

正式安装必须用管理员 cmd，不要双击opatch.bat。双击运行时工作目录和权限都不对，OPatch 可能找不到ORACLE_HOME，也可能没有权限写 inventory。执行前确认实例已经关闭、监听已经停止、补丁目录层级正确，然后进入 OPatch 目录执行apply。过程中会提示是否继续，确认补丁号和 Oracle Home 无误后再输入y。

-- 管理员 cmd 中执行，先确认环境变量 echo %ORACLE_HOME% echo %ORACLE_SID% cd /d %ORACLE_HOME%\OPatch opatch.bat apply C:\patch_tmp\35099667\35099667

echo %ORACLE_HOME%和echo %ORACLE_SID%是安装前最后一道确认。apply的补丁路径要指到含etc的目录。执行过程中 OPatch 会检查 inventory、备份部分文件、应用补丁并更新清单。看到OPatch succeeded才算文件层面完成，但这不代表数据库时区数据已经升级，后面还有datapatch和时区脚本。

如果apply中断，不要直接重跑。先看%ORACLE_HOME%\cfgtoollogs\opatch下的日志，确认是文件占用、权限问题还是补丁冲突。中断后 Oracle Home 可能处于部分应用状态，盲目重跑可能让 inventory 和实际文件不一致。必要时按日志提示回滚或恢复备份，再重新预检。

-- 安装后先确认补丁出现在清单里 cd /d %ORACLE_HOME%\OPatch opatch.bat lspatches opatch.bat lsinventory -detail > C:\backup\after_tz41_lsinventory.txt

lspatches输出当前 Oracle Home 已应用的补丁列表，lsinventory -detail留档用于对比。此时补丁文件已经进了 Oracle Home，但数据库还没有注册 SQL 变更。不要在这个阶段启动业务连接，先把datapatch和时区升级处理完。

4.2 datapatch -verbose：数据库要 OPEN，PDB 要 READ WRITE

datapatch负责把补丁里的 SQL 变更注册到数据库，包括时区相关的数据字典变更。执行前数据库要处于 OPEN 状态，CDB 里的 PDB 要打开到 READ WRITE。如果 PDB 没开，datapatch可能跳过对应容器，后面查dba_registry_sqlpatch就会看到补丁记录不完整。先起库、开 PDB，再进 OPatch 目录执行。

-- 启动实例到 OPEN，并把 PDB 打开到 READ WRITE startup show pdbs alter pluggable database all open;

-- 在 OPatch 目录执行 datapatch，输出详细过程 cd /d %ORACLE_HOME%\OPatch datapatch -verbose

startup把实例带到 OPEN，show pdbs看容器状态，alter pluggable database all open把 PDB 打开。datapatch -verbose会逐个容器注册 SQL 补丁，输出里能看到补丁号和执行状态。Windows 上有的环境对应datapatch.bat，如果直接敲datapatch不识别，就在 OPatch 目录下看实际文件名再执行。执行完再查dba_registry_sqlpatch，确认 35099667 的记录是 SUCCESS。

-- 检查 SQL 补丁注册结果 select patch_id, action, status, description from dba_registry_sqlpatch where patch_id = 35099667;

action一般是APPLY，status应该是SUCCESS。如果查不到记录，先确认是不是在正确的容器里查，再确认datapatch输出里有没有跳过该容器。如果状态是FAILED，不要继续跑时区脚本，先看datapatch日志定位失败语句。SQL 补丁失败和文件补丁失败处理方式不同，前者往往需要回退 SQL 变更或恢复数据库。

4.3 时区升级脚本：check 先行，apply 后重启

TZ41 补丁的文件应用和 SQL 注册完成后，还要确认数据库时区文件是否真正升级。常见做法是先跑utltz_upg_check.sql检查，再按 README 跑utltz_upg_apply.sql。不要一上来就执行 apply，先看检查输出提示是否需要升级、是否有不兼容数据。时区升级涉及数据字典和已有时间戳数据，生产库必须提前备份。

-- 先关闭实例，进入升级模式执行检查脚本 shutdown immediate startup upgrade @?/rdbms/admin/utltz_upg_check.sql

shutdown immediate正常关库，startup upgrade进入升级模式，@?是 SQL*Plus 里指向 Oracle Home 的写法。检查脚本会输出当前时区版本、目标版本和需要关注的对象。如果输出提示可以继续，再执行 apply 脚本；如果提示有异常数据或需要先处理的对象，先停下来按提示处理，不要强行往下走。

-- 检查通过后执行时区升级，然后正常重启 @?/rdbms/admin/utltz_upg_apply.sql shutdown immediate startup

utltz_upg_apply.sql执行完后再正常启动实例。不同补丁包的 README 可能要求先执行datapatch再跑时区脚本，也可能要求顺序相反，以补丁目录里的说明为准。Windows 下如果@?不识别，换成完整路径@D:\app\oracle\product\19.0.0\dbhome_1\rdbms\admin\utltz_upg_check.sql。脚本执行期间不要开业务连接，避免时区数据升级过程中有并发写入。

4.4 启库、启监听、检查服务与告警日志

时区升级完成后，启动监听和服务，检查告警日志里有没有 ORA- 错误。Windows 服务启动顺序一般是先起实例服务，再起监听；如果实例以服务方式管理，可以用net start，也可以让服务自动启动。启动后连进去查时区文件版本和补丁注册状态，再让应用逐步恢复连接。

-- 启动监听和服务，检查服务状态 lsnrctl start net start OracleServiceORCL net start OracleTNSListener sc query OracleServiceORCL sc query OracleTNSListener

lsnrctl start启动监听，net start启动 Windows 服务。服务名按实际环境替换，不要照抄。sc query看服务是否处于 RUNNING。启动后马上去看告警日志，路径通常在%ORACLE_BASE%\diag\rdbms\%ORACLE_SID%\%ORACLE_SID%\trace\alert_%ORACLE_SID%.log。重点看启动过程中有没有时区相关错误、数据字典错误或补丁注册失败。

-- 启动后做一次快速确认 select * from v$timezone_file; select patch_id, action, status from dba_registry_sqlpatch where patch_id = 35099667; select instance_name, status from v$instance;

v$timezone_file看时区版本是否到 41，dba_registry_sqlpatch看 SQL 补丁状态，v$instance确认实例正常打开。三项都正常，再放应用连接。如果时区版本还是旧值，回到 README 确认时区脚本是否执行、数据库是否重启过、PDB 是否都处理到。

5. 避坑与排查：TZ41 补丁在 Windows 上最容易翻车的 5 个点

5.1 补丁目录层级错，apply 报不是有效补丁位置

现象：执行opatch apply后提示补丁位置无效，或者prereq找不到etc目录。原因通常不是补丁坏了，而是解压后多了一层目录，命令指向了外层文件夹。比如补丁实际在C:\patch_tmp\35099667\35099667，命令却写成了C:\patch_tmp\35099667。OPatch 找不到补丁元数据，就会拒绝继续。

解决：先用dir /b看目录里有没有etc和files。有etc的那一层才是补丁根目录。prereq和apply都指向这一层，不要指到 zip 文件，也不要指到上一级。路径里不要带空格和中文，长度尽量短。预检通过后再执行正式 apply，避免在正式安装阶段才发现路径问题。

5.2 OPatch 版本不够或 Java 路径乱，预检失败

现象：opatch.bat version能跑，但prereq CheckApplicable报 OPatch 版本不满足要求，或者opatch.bat一启动就报 Java 类找不到。原因可能是补丁 README 要求更高版本的 OPatch，也可能是系统JAVA_HOME被改过，OPatch 没有用自己目录下的运行时。Windows 上多个 Oracle 产品共存时，PATH 里很容易混进别的 Java。

解决：先看补丁 README 的 OPatch 要求，再对比opatch.bat version输出。版本不够就按补丁说明升级 OPatch，不要直接改系统 Java。Java 报错时，检查%ORACLE_HOME%\OPatch下的日志，确认 OPatch 使用的是哪套运行时。临时把 PATH 里其他 Java 路径挪到后面，再开一个新的管理员 cmd 重试。改完环境变量要重新开窗口，旧窗口不会自动生效。

5.3 服务未停净，文件占用导致 apply 中断

现象：opatch apply执行到一半报文件无法替换、无法写入或 inventory 更新失败。原因通常是实例、监听、dbconsole 或某个客户端进程还占着 Oracle Home 里的文件。Windows 上服务停了，后台进程不一定马上退出；有时应用连接没断干净，实例也关不彻底。

解决：先lsnrctl stop，再shutdown immediate，然后sc query确认服务状态。用tasklist | findstr /i oracle看还有没有残留进程。不要直接结束oracle.exe，除非确认实例已经正常关闭。补丁中断后不要立刻重跑，先看cfgtoollogs\opatch日志，确认是文件占用还是权限问题。必要时回滚或恢复 Oracle Home 备份，再重新预检。

5.4 datapatch 没跑或 PDB 未开，SQL 补丁未注册

现象：opatch lspatches能看到 35099667，但dba_registry_sqlpatch查不到记录，或者只有部分容器有记录。原因可能是apply后直接起业务，漏了datapatch；也可能是 CDB 里 PDB 没有打开到 READ WRITE，datapatch跳过了对应容器。

解决：先show pdbs确认所有需要处理的 PDB 都是 READ WRITE，再在 OPatch 目录执行datapatch -verbose。执行完分别到根容器和 PDB 里查dba_registry_sqlpatch。如果状态是 FAILED，看datapatch日志里的失败语句，不要继续跑时区脚本。SQL 补丁失败要先处理失败原因，必要时回退 SQL 变更，再重新注册。

5.5 时区文件没升级，跨时区查询仍异常

现象：补丁清单里有 35099667，dba_registry_sqlpatch也是 SUCCESS，但v$timezone_file还是旧版本，跨时区查询结果和预期不一致。原因通常是只做了文件 apply 和datapatch，漏了utltz_upg_check.sql/utltz_upg_apply.sql，或者执行了脚本但没有正常重启实例。

解决：回到补丁 README 的 Post-installation 部分，按顺序执行检查脚本和升级脚本。执行前做数据库备份，执行时避免业务连接。升级完成后shutdown immediate再startup，不要用startup force代替正常关闭。启动后再查v$timezone_file，确认版本到 41。如果脚本报错，先处理报错对象，不要反复重跑 apply 脚本。

6. 装完怎么验证跑通：用 V$TIMEZONE_FILE 和 lspatches 做双重确认

补丁装完不要只看一句OPatch succeeded。我一般做三层确认：文件层看opatch lspatches，数据库层看dba_registry_sqlpatch，时区层看v$timezone_file。三层都对上，才让应用恢复连接。下面这组查询可以直接抄，改一下 SID 和补丁号就行。

-- 数据库层和时区层一起查 select patch_id, action, status, description from dba_registry_sqlpatch where patch_id = 35099667; select * from v$timezone_file; select instance_name, status from v$instance;

-- 文件层确认补丁在 Oracle Home 清单里 cd /d %ORACLE_HOME%\OPatch opatch.bat lspatches | findstr 35099667

dba_registry_sqlpatch里status要是SUCCESS，v$timezone_file的版本要是 41，v$instance要是 OPEN。opatch lspatches能过滤到 35099667，说明文件层已经写入。三项里任何一项对不上，都不要把问题留给业务去发现。最后再看一眼告警日志，确认启动过程中没有时区相关错误或数据字典错误。

这份 p35099667-190000-MSWIN-x86-64.zip 解决的是 Oracle 19c 在 Windows x86-64 上的 TZ41 时区文件更新，装完后的验证比安装本身更值得花时间。从那以后我每次打时区补丁，都强制走一遍“lspatches + dba_registry_sqlpatch + v$timezone_file”三重确认，不靠记忆判断。希望帮到你。

本文还有配套的精品资源，点击获取