简介PostgreSQL 18 Beta2 的 Linux 平台源码压缩包面向数据库内核研究者、数据库管理员及后端开发者用于编译安装、环境部署或内核源码学习。该版本延续了PostgreSQL在可靠性、稳定性与数据一致性上的长期积累同时处在Beta阶段适合开发者提前验证新特性、开展兼容性测试或参与社区反馈。压缩包为gz格式共2000个文件主体是1069个C语言源文件和885个头文件构成完整的编译源码树另附少量Markdown、Shell、SQL、XML、Python等文档与辅助脚本可支撑构建、配置和二次开发。包体仅27.79MB下载轻量便于快速获取。目前已有54人学习或下载。源码内容覆盖表操作、查询规划、预写日志、堆表访问、类型处理等核心子系统阅读后可深入理解MVCC、PITR、表空间、异步复制等高级机制的具体实现为二次开发、性能调优或故障排查提供底层参考也适合作为数据库原理课程的分析案例。1. postgresql-18beta2.tar.gz:一个能让你提前三个月摸到新版PostgreSQL的源码包假设你的生产环境还跑着 PostgreSQL 14 或 16,而 PostgreSQL 18 的新特性已经冻结。postgresql-18beta2.tar.gz 就是官方在功能冻结后放出的第二个公开测试版源码压缩包。它要解决一个很现实的问题:在新版本正式发布前,怎么在不动现网实例的前提下,把新内核放到一台闲置 Linux 机器上真实跑起来,而不是只看 release notes 的抽象描述。这个包适合三类人:下半年要做数据库升级评估的 DBA、所在发行版软件源里找不到新版本的运维工程师,以及正在 PostgreSQL 和 MySQL 之间做技术选型的架构师。Beta2 不是玩具,它是正式版发布前最接近最终行为的代码形态,值得花两个小时把它编译出来跑一遍。2. 下载与解压:beta2 的版本含义、校验方法和看懂源码包2.1 为什么是 beta2,而不是 alpha 或 RC别一上来就问该下载哪个版本,先看你的需求落在哪个阶段。PostgreSQL 的版本节奏是:9 月到次年 3 月开发新特性,3 月进入 beta,beta1 冻结 SQL 语法和核心 API,beta2、beta3 集中修复社区反馈的缺陷,之后出 1 到 2 个 RC,最后在 9 月末或 10 月初发布正式版。alpha 版本还在加功能、改接口,你测出来的行为到正式版可能完全变掉;RC 版本发布时间离正式版太近,留给你的评估窗口不够;beta2 正好卡在中间——功能已经长完,主要毛病清了一轮,离正式版又还有两三个月。这个时间点做升级预演和业务兼容性测试,性价比是最高的。选择源码 tar.gz 而不是二进制包,原因有三个。第一,软件源里的二进制只对应官方编译参数,你没法按需调整,比如用 --enable-debug 保留崩溃现场符号表;第二,很多发行版的软件源里 PostgreSQL 长期停留在 14、15,像麒麟 V10 这类自带软件源相对克制的国产发行版,压根不会跟进 beta;源码包几乎是唯一一条能拿到新版本 PostgreSQL 的路径。第三,源码编译能让你真正理解 PG 的目录结构和依赖边界,后面遇到问题,你知道去哪找原因,而不是把二进制当成一个黑匣子。2.2 用 SHA256 做校验:这一步省下来,后面全是玄学下载这个包,我一般建议固定官方源,不要从第三方镜像随手拉。拿到文件的第一件事是算校验和,不是解压。sha256sum 不是形式主义,一是防止网络传输损坏导致编译到一半灵异报错,二是防止拿到被替换过的文件。如果解压出来发现问题,再分辨是包的问题还是环境的问题,排查成本立刻翻倍。这一步只需要十秒钟,但能帮你省掉后面至少一个小时。# 从官方源码发布目录下载,以实际拿到的文件名和路径为准 wget -c https://ftp.postgresql.org/pub/source/v18beta2/postgresql-18beta2.tar.gz # 校验 SHA256,结果必须与官方 release 页面公布的散列值完全一致 sha256sum postgresql-18beta2.tar.gz # 校验通过后再解压;tar 会带出版本号目录 tar -xzf postgresql-18beta2.tar.gz # 进入目录,确认关键文件都在 cd postgresql-18beta2 ls -la | head -20逻辑说明:先算校验和后解压,顺序不要颠倒。wget 的 -c 参数支持断点续传,网络不稳定的环境下载大文件时很实用;解压出来的目录名自带 postgresql-18beta2,不会和你已有的 17 源码目录撞名,这为后面的多版本共存创造了条件。进入目录后别急着跑 configure,先看一眼里面的东西。接着做三件小事:确认版本号对不对、看系统需求、过一遍 configure 选项:# 核对版本号,防止从镜像站拿到内容名不符的包 grep -E PACKAGE_VERSION|PG_MAJORVERSION configure | head -5 # 查看可配置的选项清单,后面编译参数就以这里为准 ./configure --help | grep -E prefix|icu|openssl|nls|debug | head -20grep 的两行分别对应版本号和 configure 选项。跳过这一步,后面 make 时报版本号异常再回头查就晚了。--help 的 grep 只是筛选,完整参数建议从头到尾过一遍,重点留意带 with 和 without 的两组选项,它们决定启用还是禁用某个特性,直接控制后续的编译依赖。2.3 解压后先读这三个文件,别急着动手比起立刻 configure,我更建议先花五分钟看三个文件:README、doc/bugreport.html、src/test/regress/README。README 里写了系统需求,比如需要什么版本的 make、gcc、bison,照着核对你就能提前装齐依赖,而不是等到 configure 报错才返回去猜。bugreport.html 记录了这个版本已经暴露的已知问题,beta 期间有些 bug 是社区已经承认但不打算立刻修的,你先知道了就不会白折腾。src/test/regress/README 讲的是回归测试怎么跑,beta 阶段测试脚本本身也在改,先看这页能避免你跑出一个假失败还排查半天。这里有一个所有 beta 版本通用的提醒:beta 不是每天都崩的版本,真正劝退人的往往是编译依赖和测试工具链,而不是数据库本身。把依赖装齐、把测试跑通,beta 版跑起业务来和正式版差别不大。以下是 configure 选项与系统依赖的对照,建议先存下来:| configure 选项 | 系统依赖包(Debian/Ubuntu) | 不配置的影响 | | --with-icu | libicu-dev | 排序和正则退回 libc 实现,与正式版行为有差异 | | --with-openssl | libssl-dev | 无法启用 SSL 加密连接,加密链路无法验证 | | --with-perl / --with-python | libperl-dev / python3-dev | 部分 PL 语言过程函数无法使用 | | --with-readline | libreadline-dev | psql 没有命令行历史,交互体验变差 | | --enable-debug | 无 | 崩溃时没有符号表,问题极难定位 |提示:beta 版本生命周期一般只有两三个月,正式版发布后很快会出 RC 或直接 release。别在临时目录里做长期规划,每台测试机只放当前关心的那个版本,评估完再补装新版本。3. 编译三步走:configure 选项、并行 make 和时间成本3.1 先把系统依赖装齐,configure 才不会半路翻车PostgreSQL 的 configure 会在开始阶段探测编译器、make 和一堆头文件。很多人看到 configure 报错就以为源码有问题,实际百分之九十是系统缺开发包。以 Debian/Ubuntu 为例,最小依赖集合是下面这一组,一次装齐:sudo apt-get update sudo apt-get install -y build-essential \ libreadline-dev libz-dev \ bison flex libicu-dev libssl-dev \ perl libipc-run-perl逻辑说明:bison 和 flex 是语法分析器,PostgreSQL 的 SQL 解析器源码需要靠它们生成 C 代码。这两个包缺了,configure 不会报错,make 的时候才炸,所以提前装最省事。libreadline-dev 对应 psql 的行编辑和历史命令支持;libipc-run-perl 是 Perl TAP 测试的运行依赖,不装的话 make check 会跳过大半测试脚本,给你的通过其实是假象。libicu-dev 和 libssl-dev 分别是 ICU 与 OpenSSL 的头文件,只有运行库没有头文件,configure 照样卡住。这里有个容易忽略的细节:编译工具链本身也要够新。某些精简系统的 gcc 是老版本,configure 能过,编译到 PG 的新语法特性时可能报编译器内部错误。查编译器版本用 gcc --version,低于目标编译器要求就直接换系统工具链,别在旧编译器上浪费时间。3.2 configure 的五个核心参数,照着这个组合抄作业configure 参数决定你这次编译会和哪些系统库绑定。常见做法是固定三个前缀相关参数,再按需开开关。我一般这样配:mkdir -p /opt/pgsql18/data ./configure \ --prefix/opt/pgsql18 \ --with-icu \ --with-openssl \ --enable-debug \ --enable-nls参数说明:--prefix/opt/pgsql18:所有二进制和库文件装到这个独立目录。这一步直接决定你能不能和 16、17 版本共存,千万不能省,也别图省事装到 /usr/local 和现有 PG 混在一起。--with-icu:启用 ICU 排序规则。PostgreSQL 15 之后 ICU 是大趋势,beta2 的很多排序修复都围绕它展开,开着测才贴近正式版体验。--with-openssl:编译进 SSL 支持。不加也能用,但客户端加密连接、ssl 相关参数全部不可用,排查问题时就缺了一条链路。--enable-debug:保留调试符号。生产环境不建议,beta 环境强烈建议,崩溃时拿到 coredump 才有得查。--enable-nls:多语言消息支持,如果你需要看中文日志就开着,不需要可以去掉。configure 执行完会输出一段配置摘要,里面包含检测到的 ICU 版本、OpenSSL 版本、是否找到 Perl 和 Python。这一段建议截图或复制下来,后面 make check 失败时回头对照依赖状态,能帮你判断到底是环境问题还是测试代码问题。configure 本身是只读探测,不污染系统,所以参数写错了可以反复改、反复跑,没有副作用。3.3 make、make check、make install:三步顺序不能乱,也不能省configure 通过后进入编译阶段。首先关心的是并行度参数,这直接决定编译时长和会不会中途失败:# -j 后面的数字先按 CPU 核数的一半给,内存小的机器别拉满 make -j4 world # 至少跑完核心回归测试,beta 版我不建议跳过这一步 make check-world # 全部通过之后,再安装到 --prefix 指定目录 make install-world逻辑说明:make 全量编译 PostgreSQL 大约需要 5 到 15 分钟,取决于机器配置。make check-world 会跑 SQL 回归测试、TAP 测试和附加模块测试,耗时在 20 分钟到 1 小时。beta2 阶段这一步尤其值得跑,因为编译器和系统库的差异会把很多源码里没暴露的问题逼出来。装到独立目录的好处在这里体现:make install-world 只写 /opt/pgsql18,完全不会碰系统里已有的 PostgreSQL 安装。参数说明:-j4 表示同时开 4 个编译任务。8G 内存的机器拉到 -j8,经常在链接阶段被 OOM 干掉,这不是源码问题,是并行度过高。两核四线程的小机器用 -j3 就行。world 目标比默认目标多编译附加模块和文档,测 beta 用 world 更彻底。make check-world 运行结束后,重点看两样东西:测试总结里有没有 FAILED,以及 src/test/regress/log/ 下有没有新增的 regression.diffs。有 FAILED 先不要慌,记住一条原则:先确认自己的依赖版本和官方要求是否匹配,再怀疑代码 bug。beta 阶段社区已知问题通常会在 release notes 里标注,你遇到的失败大概率是环境差异,不是源码缺陷。提示:make 中途 CtrlC 中断后再次 make 一般能继续,但偶尔会留下半边生成的符号文件。稳妥做法是 make clean 后重新 make,多花几分钟换一个干净的编译状态,这笔时间花得值。3.4 configure 报错的三种典型输出怎么读configure 阶段最常见的失败有三类,学会读输出能省大量排查时间。第一类:checking for bison... no或bison: command not found。这表示系统里没有 bison,解决方式是补装,不需要改 configure 参数。第二类:checking for ICU... no或libicu not found。你开了 --with-icu 但没装 dev 包,补上 libicu-dev 后重新 configure。第三类:checking for readline... no,如果要用 psql 的历史命令功能,就装 libreadline-dev;如果是在嵌入式环境里确实没有 readline,才考虑 --without-readline,但交互体验会明显下降,我不建议测试环境这么干。每次 configure 失败后,只看最后十行输出基本就能定位问题。configure 的日志顺序是探测一个特性、打印一行结果,失败信息会紧跟对应的探测项目,不会在几百行之后藏猫腻。4. 实例初始化与 17→18 升级:beta2 能装,更要能迁移4.1 initdb 初始化:数据目录权限和两个必带参数编译装好只是第一步,要变成能连的数据库实例,还得执行 initdb。这个命令的权限要求很严格,不允许 root 直接跑,我一般用系统自带的 postgres 用户,或者自己建一个专用的数据库用户:# 数据目录单独建,别放在源码目录或 /opt/pgsql18 里面 sudo mkdir -p /var/lib/pg18data sudo chown postgres:postgres /var/lib/pg18data # 以 postgres 用户执行初始化,指定编码和本地化 sudo -u postgres /opt/pgsql18/bin/initdb \ -D /var/lib/pg18data \ -E UTF8 \ --localeC.UTF-8逻辑说明:initdb 创建的数据目录权限默认是 700,这个目录的属主必须和后续运行 postgres 进程的用户一致,否则 pg_ctl 启动时会直接拒绝访问。编码指定 UTF8 是最稳妥的起点,避免测试过程中陷入中文编码的泥潭。--locale 用 C.UTF-8 而不是 en_US.UTF-8,是为了绕开系统 locale 缺失时的报错——很多精简容器镜像里根本没有 en_US 的 locale 文件,但 C.UTF-8 基本都存在。initdb 执行完毕会输出 Success 示意,注意提示里的两行:一行是默认超级用户,默认取当前系统用户名,这里就是 postgres;另一行是默认数据库名,Ubuntu 系同样叫 postgres。后面 psql 连接用的就是这一组账号和库名。4.2 pg_ctl 启停和 psql 连通性验证启动实例建议用 pg_ctl 而不是手动去后台跑 postgres 进程,因为 pg_ctl 会统一管理 PID 文件、日志重定向和退出状态码,方便脚本化控制:# -l 指定日志文件,避免启动失败时连报错都找不到 sudo -u postgres /opt/pgsql18/bin/pg_ctl \ -D /var/lib/pg18data \ -l /var/lib/pg18data/server.log \ start # 确认进程和端口 pgrep -a postgres ss -ltn | grep 5432 # 用完整路径的 psql 连接,避免 PATH 里混入旧版本客户端 /opt/pgsql18/bin/psql -U postgres -d postgres \ -c SELECT version();这里有一个容易翻车的细节:很多人启动成功后直接在终端敲 psql,结果连上的是系统自带的旧版客户端或旧版服务,看到版本号对不上才慌。所以示例里特意用 /opt/pgsql18/bin/psql 全路径执行。ss 查看端口确认监听 5432,才算在新版本层面注册了网络入口。日志文件里出现 database system is ready to accept connections 才是真正启动完成,而不是看到 postgres 进程存在就以为没问题。4.3 从 17 升级到 18:beta2 环境下通用的 pg_upgrade 路径升级评估是测 beta 的核心目的之一。PostgreSQL 的 pg_upgrade 支持跨大版本原地升级,17 到 18beta2 也能用,前提是:新旧两个版本的二进制都在,两个数据目录都可用,旧的 17 实例处于停止状态。完整流程我平时是这样操作的:# 1. 停掉准备升级的 17 实例 sudo -u postgres /opt/pgsql17/bin/pg_ctl -D /var/lib/pg17data stop # 2. 用 18 的 initdb 建一个全新的空数据目录 sudo -u postgres /opt/pgsql18/bin/initdb \ -D /var/lib/pg18data -E UTF8 --localeC.UTF-8 # 3. 执行升级,--link 用硬链接加速迁移,极快但有代价 sudo -u postgres /opt/pgsql18/bin/pg_upgrade \ -b /opt/pgsql17/bin \ -B /opt/pgsql18/bin \ -d /var/lib/pg17data \ -D /var/lib/pg18data \ -j 4 \ --link参数说明:-b 和 -B 分别指向 17 和 18 的 bin 目录,pg_upgrade 靠这两个路径调出对应版本的 pg_ctl、pg_dump 等工具;-d 和 -D 是旧数据目录和新数据目录;-j 4 是并行处理表文件的线程数,核多可以加到 -j8;--link 是硬链接模式,直接把旧数据文件链接到新目录,几百 GB 的库几秒钟迁移完,代价是升级完成后旧目录不能再单独使用。pg_upgrade 跑完会打印成功信息,接着启动新的 18 实例,你就能看到 17 里的表、索引、视图、函数全部原样出现在新版本里。这个过程中一半的时间是花在排错上,最常见的三个问题:扩展插件不兼容、旧实例没有干净停掉、新旧数据目录权限不一致。扩展问题在第 5 章展开,这里先给一张升级后基线检查表,按顺序执行,跑完一遍心里就有底了:| 检查项 | 命令 | 通过标准 | | 实例启动 | pg_ctl -D /var/lib/pg18data start | 日志出现 ready to accept connections | | 版本确认 | psql -c SELECT version() | 返回 PostgreSQL 18beta2 | | 核心数据 | psql -c SELECT count(*) FROM ... | 与升级前记录的行数一致 | | 权限校验 | psql -c SELECT * FROM information_schema.role_table_grants | 关键账号权限完整 | | 扩展加载 | psql -c SELECT * FROM pg_extension | 无 interrupted 或 missing 状态 |提示:beta2 升级到正式版,官方不提供直接从 beta 通道升级的入口,到时还需要再跑一次 pg_upgrade。测试环境数据量不用大,建一张带数据的表、一个视图、一个存储过程,就足以验证整条升级链路。5. 避坑:beta2 编译安装容易踩的 5 个翻车点与解决路径以下五条不按概率排,只按我遇到时的痛苦程度排。每条都按现象、原因、解决三步写明白,你遇到类似现象时直接对号入座。5.1 configure 能过,make 却报 bison 版本太老现象:configure 检查一路绿灯,make 执行到 src/backend/parser 时突然报错,提示 bison 版本过低或语法规则无法生成,一堆 parser 相关的 C 文件没有生成出来。原因:PostgreSQL 的 SQL 语法文件对 bison 有最低版本要求,官方文档里长期标注的是 bison 不低于 2.3。很多精简系统的 bison 是 1.x 或者特别老的 2.x,configure 对 bison 的检查停留在命令存在层面,最多给个警告,真正卡死在编译期。这种情况在 CentOS 6、某些国产 Linux 精简版里特别常见。解决:先执行 bison --version 确认版本,低于要求就直接换。CentOS 系可以单独编译安装新版 bison 到 /usr/local,然后把 /usr/local/bin 放到 PATH 前面;Ubuntu 系直接 apt install bison 就会带 3.x。系统自带的旧 bison 不用卸载,只要 PATH 里优先命中新版即可。改完 PATH 后重新 make clean,再 make,不要在旧状态上直接续编译。5.2 make check-world 秒级跑完,全是 skip,你还以为通过了现象:check-world 跑得飞快,输出大片的 skip,总结里没有 FAILED,你以为测试全部通过,实际上有价值的测试几乎没跑。原因:缺少 Perl 的 IPC::Run 模块。PostgreSQL 的 TAP 测试用 Perl 编排,大约一半的测试脚本强依赖它。系统里没有 IPC::Run 时,测试框架的策略是跳过而不是报错,于是你看到的就是一个表面干净的 skip 列表。解决:Ubuntu/Debian 安装 libipc-run-perl,CentOS/RHEL 安装 perl-IPC-Run,装完重新 make check-world。判断依据很简单:如果 skip 数量占了总测试的六成以上,先怀疑测试依赖,不是源码问题。这一步最常见的血泪教训是测试通过了,上生产才炸,beta 环境里尤其不能容忍这种假通过。5.3 新装的 psql 连上旧库,报 client version mismatch现象:18 的实例明明已经启动,psql 连上去却报 server version (18beta2) and client version (17.x) mismatch,你确认自己连的是 18 的端口,客户端版本却对不上。原因:PATH 环境变量里 17 的 bin 目录排在 18 前面,终端找到的是旧客户端。PostgreSQL 的客户端和服务器在大版本之间不保证协议兼容,17 的 psql 去连 18 的服务,会直接拒绝执行。解决:用全路径 /opt/pgsql18/bin/psql,或者把 /opt/pgsql18/bin 放到 PATH 的首位。多版本切换更推荐写一个小脚本定义环境变量,比如 alias pg18export PATH/opt/pgsql18/bin:$PATH,不要每次临时 export,关掉终端就丢,下次再踩同一个坑。多版本共存环境下,养成先确认 which psql,再执行 SQL的习惯,能避免大量灵异现象。5.4 pg_upgrade 用了 --link,升级完旧目录直接没法用了现象:pg_upgrade --link 成功,新实例跑起来一切正常,回头想启动一下旧 17 实例留作备份,发现数据文件已经被接管,旧库完全起不来,数据好像被冲掉了。原因:--link 不是复制,是通过硬链接把旧数据文件链接到新目录。升级过程中新库对文件的任何写入,都会直接反映到物理底层文件上;升级完成后,旧目录本质上只是新目录的另一组入口,不再是一个独立可用的数据目录。很多人没意识到 --link 的这个隐含语义,以为旧目录还是备份。解决:执行升级前想清楚一件事:用了 --link,就等于决定放弃旧目录,升级完成后不要启动旧实例,也别再往旧目录里写任何东西。如果确实需要旧库作为双保险,去掉 --link,用默认的复制模式,代价是迁移时间随数据量线性增长。测试环境数据量小,直接复制模式最省心,一条命令都不需要改,只删掉 --link 即可。数据量大的生产预演,才值得用 --link 换速度,同时接受旧库不可回退的现实。5.5 升级后扩展插件全部加载失败现象:pg_upgrade 完成后,启动 18 实例,日志里出现 could not open extension control file 或者 extension not found,pg_extension 视图里一片异常状态。原因:扩展,尤其是 PostGIS 这类 C 语言扩展,是针对特定大版本编译的。17 环境下编译的扩展 SO 文件无法直接在 18 的内核里加载;即使是 pg_stat_statements 这类内置扩展,它的动态库文件也要跟随主版本重新安装。pg_upgrade 本身不负责帮你重编扩展,它只迁移数据。解决:在新源码目录下重新 make 并 install 对应的扩展模块,然后在新实例上重新执行 CREATE EXTENSION。如果升级评估的前提是必须带 PostGIS,顺序应该是:先在 18 的源码环境里把 PostGIS 编译安装完,再跑 pg_upgrade,而不是升级完再回头补扩展。另外提醒一点,beta 版本的动态库文件在正式版发布后还要重新编译一次,扩展这块在 beta 阶段能跑通流程即可,别追求一次到位。6. 用独立目录做多版本共存,把 beta2 变成日常回归工具beta2 生命周期短,但如果利用得当,它不只是测试品。我个人的习惯是在测试服务器上建 /opt/pgsql17、/opt/pgsql18 两个独立安装目录,数据目录对应 /var/lib/pg17data、/var/lib/pg18data,配合一个环境切换函数,切到哪个版本,psql 和 pg_ctl 就自动指向哪个。这样每次有新的 PostgreSQL 大版本发布,新增一个目录就能起一套完整环境,历史版本完全不受影响。use_pg18() { export PATH/opt/pgsql18/bin:$PATH export PGDATA/var/lib/pg18data export PGPORT5433 } use_pg18 psql -U postgres -d postgres -c SELECT version();这样做最大的价值在于:回归测试不再是 beta2 的一次性任务。每当社区推送新补丁,你在这个环境里重跑一遍自己的核心 SQL 用例,几秒钟就能确认业务兼容性;等正式版出来,把目录和端口换掉再重跑一遍,就是完整的升级预演。我经历过的多次升级,真正劝退人的从来不是技术难题,而是临场才发现旧 SQL 写法在语法层级不兼容,这种问题只有靠日常回归才能提前拦下来。另外还有两个小技巧一并交代。第一,make 时如果只想验证解析器或某个模块的改动,可以用 make -C src/backend/parser 单独编子目录,省掉全量编译的时间;第二,调试崩溃现场时,给 postgres 进程加 -c log_min_messagesdebug5 临时提升日志级别,很多看着诡异的报错在 debug5 日志里会直接露出根源。这两个技巧帮我解决过不少现象让人摸不着头脑、根因简单得让人发笑的问题,几乎每次调试完都会确认一次:日志里的信息比猜测可靠得多。说回这个源码包本身,beta2 的安装和升级流程并不复杂,复杂的是围绕它的环境管理和升级预演。把上面这套流程完整跑过一遍,你会对 PostgreSQL 的源码结构、依赖边界和升级机制建立真正属于自己的判断,而不是听别人转述。希望这次整理能帮到你,也希望你的 beta 环境里少几个翻车时刻。本文还有配套的精品资源点击获取