聊聊我自己的翻车经历。刚接触PostgreSQL那阵子我敲下\l查看数据库列表发现集群里默认躺着三个库postgres、template0、template1。当时也没多想以为就是自带的演示数据。直到有一次我在测试环境手滑执行了DROP DATABASE template1再敲CREATE DATABASE的时候直接报错——默认模板都没了你让新库从哪儿复制那次事故之后我才真正明白PostgreSQL模板数据库不是一个可有可无的概念而是整个建库机制的根基。这篇文章就把模板数据库这件事讲透三个内置模板各自的分工、CREATE DATABASE底层到底复制了什么、怎样做一个带pgvector扩展的自定义模板库以及你大概率会遇到的高频报错和排查思路。适合刚入门的PG新手也适合用了很久却从没细究过默认库角色的老同学。1. 三个内置模板库的分工谁是毛坯房谁是样板间1.1 template1默认的“精装样板间”如果你执行CREATE DATABASE xxx时不带任何参数PG就会以template1为模板复制出一个新库。也就是说template1是默认的模板库你在里面装的扩展、建的表、定义的函数都会“遗传”给之后所有新库。很多团队会把通用扩展比如pgcrypto、hstore预装到template1里新库开箱即用。这里有个很重要的习惯问题生产环境我一般不建议随便改template1。原因不复杂——它的影响范围是“所有后续新建的库”一旦改错等于给公司未来上线的每一个数据库都埋了雷。如果你只是想让一部分数据库带某些公共对象更稳的做法是建一个自定义模板库而不是动template1。这个我们第三节专门讲。你可以做个快速验证在 psql 里执行下面的语句会看到template1的datistemplate字段是true说明它被标记为“可作为模板”。SELECT datname, datistemplate, datallowconn FROM pg_database;1.2 template0永远保持出厂状态的“毛坯房”template0是一个特殊的存在它的datallowconn是false也就是说普通客户端根本连不进去只能作为“复制源”存在。为什么要有这样一个连都不能连的库因为它要保证绝对的干净——你在template1里做的任何修改都不会影响template0所以它是紧急恢复和跨语言环境建库时最可靠的底子。举个例子你想建一个指定 UTF8 编码、指定排序规则的新库而template1里的配置跟目标不一致PG 会自动改用template0来复制。官方文档里也写得很明确——当目标库的 locale 或 encoding 与template1不同时系统会自动切换到template0。如果你自己手动把template0弄脏等于把这条唯一的退路堵死了。1.3 postgres它是普通库不是模板很多人以为postgres是“主数据库”或者“模板之一”其实它就是一个普普通通的数据库datistemplate为false。唯一的区别在于它在集群初始化时自动创建而且很多工具默认会连到postgres库来执行维护操作。我个人的习惯是日常运维连接就用postgres库尤其是需要执行CREATE DATABASE或者删除数据库的维护命令时把它当成一个“工作台”。但要注意postgres库最好不要删也别往里放业务表。一旦它被业务数据占满可能直接影响后续维护操作。数据库datistemplatedatallowconn作用template0truefalse最干净的兜底模板不可连接用于恢复和跨 locale 建库template1truetrue默认建库模板可修改影响所有不带 TEMPLATE 的新库postgresfalsetrue普通库常作为维护连接的工作台2. CREATE DATABASE 的底层复制原理2.1 datistemplate 这个开关到底控制了啥模板机制的核心就是pg_database表里的两个布尔字段datistemplate和datallowconn。datistemplate为true表示这个库可以被当作新建数据库的“母本”datallowconn为false表示禁止客户端直接连接。两者共同作用构成了模板数据库的访问边界。你可以执行SELECT * FROM pg_database;看看这些字段还能看到每个库的 encoding、collate、ctype 等属性。这些属性在建库时非常关键因为 PG 复制模板时不是简单“拷贝一份数据”它必须保证新库的编码和排序规则与模板兼容。如果从 MySQL 转过来这个设计思维差异要最先适应。2.2 复制模板的时候到底复制了什么一句话模板库里的所有东西都会被复制包括表、视图、函数、扩展、数据类型、默认权限等。你可以把CREATE DATABASE想象成“对一个文件系统快照做克隆”而不是用 SQL 语句去重新执行一遍建表脚本。这也是为什么它能比“导出再导入”快得多。但有几个东西不会复制active session 肯定不在其中postgresql.conf这种实例级配置也不会复制服务端连接参数、监听设置等同样跟新库无关。这里我建议你实际建一个自定义模板库测试一下把要公共化的对象放进去然后克隆再检查——最可靠的验证方式永远是实测而不是猜。2.3 PG15 开始的复制策略WAL_LOG 与 FILE_COPY在 PG15 之前CREATE DATABASE主要靠 WAL 日志记录整个建库过程好处是崩溃安全代价是大库建库慢。PG15 开始引入了FILE_COPY策略直接复制模板库文件速度更快但建库期间需要额外磁盘空间。实操中怎么选如果是几十 GB 以上的大模板我会用STRATEGY FILE_COPY如果磁盘紧张就老老实实用默认的WAL_LOG。完整的命令如下CREATE DATABASE newdb TEMPLATE mytemplate STRATEGY FILE_COPY;这个参数在 PG15 以下版本不识别使用前先确认版本。其实对于大多数业务场景默认策略已经够用FILE_COPY更多是给超大规模模板库准备的优化项。3. 实战做一个带 pgvector 扩展的自定义模板库3.1 场景设定每个新库都要带向量检索能力最近pgvector很火很多项目要上向量检索。但你发现没有pgvector装完后扩展是“库级”的也就是说每个数据库都要单独执行一次CREATE EXTENSION vector;。如果公司有几十个业务库手动操作很烦也容易漏。更优雅的方案是做一个自定义模板库把vector扩展提前装进去以后所有从这个模板克隆出来的库天然自带向量功能。这比你每上一个新项目就从头折腾一遍要省太多时间。类似的需求还包括公共函数、统一审计字段、默认权限等都可以通过模板库一次性解决。3.2 完整操作步骤在 psql 中以超级用户执行以下操作-- 1. 创建模板库基于 template0 保证绝对干净 CREATE DATABASE mytemplate WITH ENCODING UTF8 LC_COLLATE en_US.UTF-8 LC_CTYPE en_US.UTF-8 TEMPLATE template0; -- 2. 连进去创建公共扩展 \c mytemplate CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION IF NOT EXISTS pgcrypto; -- 3. 按需定义公共函数或默认权限 -- 例如CREATE FUNCTION 或者 ALTER DEFAULT PRIVILEGES ... -- 4. 退出连接把库标记为模板 -- 注意要确保没有其他连接 UPDATE pg_database SET datistemplate true WHERE datname mytemplate; -- 5. 验证基于模板创建新库 CREATE DATABASE new_biz_db TEMPLATE mytemplate; -- 6. 检查新库扩展 \c new_biz_db \dx第 4 步之前一定要确保没有其他会话连接着mytemplate。否则之后执行CREATE DATABASE ... TEMPLATE mytemplate时会直接报“源数据库正在被其它用户访问”。所以模板库建成后最好不要再让业务连接它只把它当作一个“工厂母机”。3.3 改回普通库的方法与注意事项如果你做完了模板不再需要它了可以把它改回普通库UPDATE pg_database SET datistemplate false WHERE datname mytemplate;注意如果这个库目前正在被其它会话连接你无法直接DROP DATABASE。生产环境要先清理连接SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname mytemplate AND pid pg_backend_pid();然后执行DROP DATABASE mytemplate;。这里我特别提醒一句清理连接的 SQL 杀伤力很大执行前一定确认过滤条件别把生产库的会话也给杀了。4. 高频报错与故障排查链路4.1 连不上 template0is not currently accepting connections刚接触PG的人容易犯一个错看到template0想进去看看里面有什么结果报错database template0 is not currently accepting connections这不是权限问题而是这个库被刻意设置了datallowconn false。想临时查看它的内容可以先把datallowconn改成true连接进去用完立刻改回并断开。但我的建议是非必要别这么干template0是恢复用的最后退路保持它的干净状态价值远大于你进去看一眼的好奇心。4.2 克隆时报“源数据库正在被其他用户访问”这是创建数据库时最典型的报错ERROR: source database mytemplate is being accessed by other users DETAIL: There are 3 other sessions using the database.原因是模板库里有连接存在导致无法复制。解决办法是终止掉那些会话再看是否还有空闲连接。注意pg_stat_activity里的idle连接也会阻塞建库不要只盯着 active 状态的连接。SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname mytemplate AND pid pg_backend_pid();执行完后再确认一次SELECT count(*) FROM pg_stat_activity WHERE datname mytemplate;返回 0 之后再执行建库命令。4.3 编码或排序规则不匹配导致建库失败如果你的模板库是 UTF8而新库想用别的编码PG 会直接报不匹配并提醒你用template0。更准确的说法是只要目标库的ENCODING、LC_COLLATE、LC_CTYPE与模板库不一致系统就会改用template0来复制。这种情况下的标准做法就是显式指定TEMPLATE template0和你要的编码/排序参数比如CREATE DATABASE app_db WITH TEMPLATE template0 ENCODING UTF8 LC_COLLATE zh_CN.UTF-8 LC_CTYPE zh_CN.UTF-8;这条命令在很多运维场景里属于“必须背下来”的救命语句尤其是接手别人搭建的集群时鬼知道当时的template1被改成了什么参数。4.4 启动超时等待服务器启动时超时与模板库的关联热搜里有个高频问题PostgreSQL 数据库启动失败提示“等待服务器启动时超时”。多数情况下跟模板数据库没有直接关系常见原因是端口被占用、数据目录权限不对、内存不足、或postgresql.conf配置异常。排查顺序应该是看日志数据目录下的 log 文件比如postgresql-日期.log检查端口netstat -an | grep 5432排除端口占用检查数据目录权限chown -R postgres:postgres 数据目录检查内存和交换分区确认是否启动时资源不够如果日志里出现和模板库或pg_database相关的损坏信息说明系统表出了问题。如果确实遇到模板库文件损坏导致启动失败通常不是单靠 SQL 能修的得从备份恢复或者在完全停库后谨慎处理数据目录相关文件。这方面的操作风险极高生产环境务必先备份再动。我见过太多人试图“修复”模板库结果把整个数据目录搞得更乱。记住一条原则没有备份的情况下不要做任何破坏性操作。5. 从 MySQL 转过来的同学模板机制到底哪里不一样5.1 MySQL 没有模板库如果你是从 MySQL 切过来的最需要建立的一个认知是MySQL 建库本质是在数据目录里创建一个目录附带默认字符集设置而 PostgreSQL 建库本质是“复制一个模板库”所以模板库的质量直接决定了新库的质量。这个差异带来的连锁反应是PG 里你可以在模板库里预置一切公共对象新库秒级继承MySQL 做不到这种程度的“库级复制”。所以很多 PG 团队会有“基础模板库 版本管理”的做法这在 MySQL 运维里不太常见。如果你之前习惯在 MySQL 里靠初始化脚本挨个建表到了 PG 一定得改掉这个习惯用模板库会省力得多。5.2 语句差异对照场景MySQLPostgreSQL建库CREATE DATABASE app DEFAULT CHARSET utf8mb4;CREATE DATABASE app TEMPLATE template0 ENCODING UTF8 LC_COLLATE ...;字符集CHARSET 是建库时指定集群初始化时决定建库时可显式指定 ENCODING公共对象继承无模板库机制通过模板库继承扩展、表、函数系统库information_schema、performance_schematemplate0、template1、postgres另外MySQL 里的information_schema、performance_schema、sys这些是系统库跟 PG 的template0、template1、postgres完全不是一个东西不要混淆。前者是元数据视图和性能监控后者是真正参与建库复制流程的实体库。5.3 三个最容易踩的坑手滑改 template1默认所有新库都会被影响。改之前一定想清楚影响面。直接删 postgres 库很多工具默认连它执行维护删了之后部分管理操作会变得麻烦。忽视 locale 差异从 MySQL 带过来的习惯可能是utf8mb4对应到 PG 是ENCODING加LC_COLLATE/LC_CTYPE建库时不匹配会直接失败。最后说个我自己的习惯每搭好一套 PG 环境我都会顺手验证一遍模板库的可用性。方法是用template0克隆一个测试库再用默认方式克隆一个测试库确认两条链路都是通的。这个验证只要几秒钟但能在关键时刻避免“建库失败”引发的连锁事故。模板数据库这东西平时安安静静躺在那里感觉不到存在等你真正需要它的时候才发现它其实是整个 PG 环境里最不该忽视的基础设施。 
长河君 · 2026/9/24 19:43:45 · 阅读 1.2k PostgreSQL模板数据库详解：从三个默认库到pgvector自定义模板
聊聊我自己的翻车经历。刚接触PostgreSQL那阵子我敲下\l查看数据库列表发现集群里默认躺着三个库postgres、template0、template1。当时也没多想以为就是自带的演示数据。直到有一次我在测试环境手滑执行了DROP DATABASE template1再敲CREATE DATABASE的时候直接报错——默认模板都没了你让新库从哪儿复制那次事故之后我才真正明白PostgreSQL模板数据库不是一个可有可无的概念而是整个建库机制的根基。这篇文章就把模板数据库这件事讲透三个内置模板各自的分工、CREATE DATABASE底层到底复制了什么、怎样做一个带pgvector扩展的自定义模板库以及你大概率会遇到的高频报错和排查思路。适合刚入门的PG新手也适合用了很久却从没细究过默认库角色的老同学。1. 三个内置模板库的分工谁是毛坯房谁是样板间1.1 template1默认的“精装样板间”如果你执行CREATE DATABASE xxx时不带任何参数PG就会以template1为模板复制出一个新库。也就是说template1是默认的模板库你在里面装的扩展、建的表、定义的函数都会“遗传”给之后所有新库。很多团队会把通用扩展比如pgcrypto、hstore预装到template1里新库开箱即用。这里有个很重要的习惯问题生产环境我一般不建议随便改template1。原因不复杂——它的影响范围是“所有后续新建的库”一旦改错等于给公司未来上线的每一个数据库都埋了雷。如果你只是想让一部分数据库带某些公共对象更稳的做法是建一个自定义模板库而不是动template1。这个我们第三节专门讲。你可以做个快速验证在 psql 里执行下面的语句会看到template1的datistemplate字段是true说明它被标记为“可作为模板”。SELECT datname, datistemplate, datallowconn FROM pg_database;1.2 template0永远保持出厂状态的“毛坯房”template0是一个特殊的存在它的datallowconn是false也就是说普通客户端根本连不进去只能作为“复制源”存在。为什么要有这样一个连都不能连的库因为它要保证绝对的干净——你在template1里做的任何修改都不会影响template0所以它是紧急恢复和跨语言环境建库时最可靠的底子。举个例子你想建一个指定 UTF8 编码、指定排序规则的新库而template1里的配置跟目标不一致PG 会自动改用template0来复制。官方文档里也写得很明确——当目标库的 locale 或 encoding 与template1不同时系统会自动切换到template0。如果你自己手动把template0弄脏等于把这条唯一的退路堵死了。1.3 postgres它是普通库不是模板很多人以为postgres是“主数据库”或者“模板之一”其实它就是一个普普通通的数据库datistemplate为false。唯一的区别在于它在集群初始化时自动创建而且很多工具默认会连到postgres库来执行维护操作。我个人的习惯是日常运维连接就用postgres库尤其是需要执行CREATE DATABASE或者删除数据库的维护命令时把它当成一个“工作台”。但要注意postgres库最好不要删也别往里放业务表。一旦它被业务数据占满可能直接影响后续维护操作。数据库datistemplatedatallowconn作用template0truefalse最干净的兜底模板不可连接用于恢复和跨 locale 建库template1truetrue默认建库模板可修改影响所有不带 TEMPLATE 的新库postgresfalsetrue普通库常作为维护连接的工作台2. CREATE DATABASE 的底层复制原理2.1 datistemplate 这个开关到底控制了啥模板机制的核心就是pg_database表里的两个布尔字段datistemplate和datallowconn。datistemplate为true表示这个库可以被当作新建数据库的“母本”datallowconn为false表示禁止客户端直接连接。两者共同作用构成了模板数据库的访问边界。你可以执行SELECT * FROM pg_database;看看这些字段还能看到每个库的 encoding、collate、ctype 等属性。这些属性在建库时非常关键因为 PG 复制模板时不是简单“拷贝一份数据”它必须保证新库的编码和排序规则与模板兼容。如果从 MySQL 转过来这个设计思维差异要最先适应。2.2 复制模板的时候到底复制了什么一句话模板库里的所有东西都会被复制包括表、视图、函数、扩展、数据类型、默认权限等。你可以把CREATE DATABASE想象成“对一个文件系统快照做克隆”而不是用 SQL 语句去重新执行一遍建表脚本。这也是为什么它能比“导出再导入”快得多。但有几个东西不会复制active session 肯定不在其中postgresql.conf这种实例级配置也不会复制服务端连接参数、监听设置等同样跟新库无关。这里我建议你实际建一个自定义模板库测试一下把要公共化的对象放进去然后克隆再检查——最可靠的验证方式永远是实测而不是猜。2.3 PG15 开始的复制策略WAL_LOG 与 FILE_COPY在 PG15 之前CREATE DATABASE主要靠 WAL 日志记录整个建库过程好处是崩溃安全代价是大库建库慢。PG15 开始引入了FILE_COPY策略直接复制模板库文件速度更快但建库期间需要额外磁盘空间。实操中怎么选如果是几十 GB 以上的大模板我会用STRATEGY FILE_COPY如果磁盘紧张就老老实实用默认的WAL_LOG。完整的命令如下CREATE DATABASE newdb TEMPLATE mytemplate STRATEGY FILE_COPY;这个参数在 PG15 以下版本不识别使用前先确认版本。其实对于大多数业务场景默认策略已经够用FILE_COPY更多是给超大规模模板库准备的优化项。3. 实战做一个带 pgvector 扩展的自定义模板库3.1 场景设定每个新库都要带向量检索能力最近pgvector很火很多项目要上向量检索。但你发现没有pgvector装完后扩展是“库级”的也就是说每个数据库都要单独执行一次CREATE EXTENSION vector;。如果公司有几十个业务库手动操作很烦也容易漏。更优雅的方案是做一个自定义模板库把vector扩展提前装进去以后所有从这个模板克隆出来的库天然自带向量功能。这比你每上一个新项目就从头折腾一遍要省太多时间。类似的需求还包括公共函数、统一审计字段、默认权限等都可以通过模板库一次性解决。3.2 完整操作步骤在 psql 中以超级用户执行以下操作-- 1. 创建模板库基于 template0 保证绝对干净 CREATE DATABASE mytemplate WITH ENCODING UTF8 LC_COLLATE en_US.UTF-8 LC_CTYPE en_US.UTF-8 TEMPLATE template0; -- 2. 连进去创建公共扩展 \c mytemplate CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION IF NOT EXISTS pgcrypto; -- 3. 按需定义公共函数或默认权限 -- 例如CREATE FUNCTION 或者 ALTER DEFAULT PRIVILEGES ... -- 4. 退出连接把库标记为模板 -- 注意要确保没有其他连接 UPDATE pg_database SET datistemplate true WHERE datname mytemplate; -- 5. 验证基于模板创建新库 CREATE DATABASE new_biz_db TEMPLATE mytemplate; -- 6. 检查新库扩展 \c new_biz_db \dx第 4 步之前一定要确保没有其他会话连接着mytemplate。否则之后执行CREATE DATABASE ... TEMPLATE mytemplate时会直接报“源数据库正在被其它用户访问”。所以模板库建成后最好不要再让业务连接它只把它当作一个“工厂母机”。3.3 改回普通库的方法与注意事项如果你做完了模板不再需要它了可以把它改回普通库UPDATE pg_database SET datistemplate false WHERE datname mytemplate;注意如果这个库目前正在被其它会话连接你无法直接DROP DATABASE。生产环境要先清理连接SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname mytemplate AND pid pg_backend_pid();然后执行DROP DATABASE mytemplate;。这里我特别提醒一句清理连接的 SQL 杀伤力很大执行前一定确认过滤条件别把生产库的会话也给杀了。4. 高频报错与故障排查链路4.1 连不上 template0is not currently accepting connections刚接触PG的人容易犯一个错看到template0想进去看看里面有什么结果报错database template0 is not currently accepting connections这不是权限问题而是这个库被刻意设置了datallowconn false。想临时查看它的内容可以先把datallowconn改成true连接进去用完立刻改回并断开。但我的建议是非必要别这么干template0是恢复用的最后退路保持它的干净状态价值远大于你进去看一眼的好奇心。4.2 克隆时报“源数据库正在被其他用户访问”这是创建数据库时最典型的报错ERROR: source database mytemplate is being accessed by other users DETAIL: There are 3 other sessions using the database.原因是模板库里有连接存在导致无法复制。解决办法是终止掉那些会话再看是否还有空闲连接。注意pg_stat_activity里的idle连接也会阻塞建库不要只盯着 active 状态的连接。SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname mytemplate AND pid pg_backend_pid();执行完后再确认一次SELECT count(*) FROM pg_stat_activity WHERE datname mytemplate;返回 0 之后再执行建库命令。4.3 编码或排序规则不匹配导致建库失败如果你的模板库是 UTF8而新库想用别的编码PG 会直接报不匹配并提醒你用template0。更准确的说法是只要目标库的ENCODING、LC_COLLATE、LC_CTYPE与模板库不一致系统就会改用template0来复制。这种情况下的标准做法就是显式指定TEMPLATE template0和你要的编码/排序参数比如CREATE DATABASE app_db WITH TEMPLATE template0 ENCODING UTF8 LC_COLLATE zh_CN.UTF-8 LC_CTYPE zh_CN.UTF-8;这条命令在很多运维场景里属于“必须背下来”的救命语句尤其是接手别人搭建的集群时鬼知道当时的template1被改成了什么参数。4.4 启动超时等待服务器启动时超时与模板库的关联热搜里有个高频问题PostgreSQL 数据库启动失败提示“等待服务器启动时超时”。多数情况下跟模板数据库没有直接关系常见原因是端口被占用、数据目录权限不对、内存不足、或postgresql.conf配置异常。排查顺序应该是看日志数据目录下的 log 文件比如postgresql-日期.log检查端口netstat -an | grep 5432排除端口占用检查数据目录权限chown -R postgres:postgres 数据目录检查内存和交换分区确认是否启动时资源不够如果日志里出现和模板库或pg_database相关的损坏信息说明系统表出了问题。如果确实遇到模板库文件损坏导致启动失败通常不是单靠 SQL 能修的得从备份恢复或者在完全停库后谨慎处理数据目录相关文件。这方面的操作风险极高生产环境务必先备份再动。我见过太多人试图“修复”模板库结果把整个数据目录搞得更乱。记住一条原则没有备份的情况下不要做任何破坏性操作。5. 从 MySQL 转过来的同学模板机制到底哪里不一样5.1 MySQL 没有模板库如果你是从 MySQL 切过来的最需要建立的一个认知是MySQL 建库本质是在数据目录里创建一个目录附带默认字符集设置而 PostgreSQL 建库本质是“复制一个模板库”所以模板库的质量直接决定了新库的质量。这个差异带来的连锁反应是PG 里你可以在模板库里预置一切公共对象新库秒级继承MySQL 做不到这种程度的“库级复制”。所以很多 PG 团队会有“基础模板库 版本管理”的做法这在 MySQL 运维里不太常见。如果你之前习惯在 MySQL 里靠初始化脚本挨个建表到了 PG 一定得改掉这个习惯用模板库会省力得多。5.2 语句差异对照场景MySQLPostgreSQL建库CREATE DATABASE app DEFAULT CHARSET utf8mb4;CREATE DATABASE app TEMPLATE template0 ENCODING UTF8 LC_COLLATE ...;字符集CHARSET 是建库时指定集群初始化时决定建库时可显式指定 ENCODING公共对象继承无模板库机制通过模板库继承扩展、表、函数系统库information_schema、performance_schematemplate0、template1、postgres另外MySQL 里的information_schema、performance_schema、sys这些是系统库跟 PG 的template0、template1、postgres完全不是一个东西不要混淆。前者是元数据视图和性能监控后者是真正参与建库复制流程的实体库。5.3 三个最容易踩的坑手滑改 template1默认所有新库都会被影响。改之前一定想清楚影响面。直接删 postgres 库很多工具默认连它执行维护删了之后部分管理操作会变得麻烦。忽视 locale 差异从 MySQL 带过来的习惯可能是utf8mb4对应到 PG 是ENCODING加LC_COLLATE/LC_CTYPE建库时不匹配会直接失败。最后说个我自己的习惯每搭好一套 PG 环境我都会顺手验证一遍模板库的可用性。方法是用template0克隆一个测试库再用默认方式克隆一个测试库确认两条链路都是通的。这个验证只要几秒钟但能在关键时刻避免“建库失败”引发的连锁事故。模板数据库这东西平时安安静静躺在那里感觉不到存在等你真正需要它的时候才发现它其实是整个 PG 环境里最不该忽视的基础设施。