PostgreSQL的域类型通过封装约束和默认值提升数据建模的严谨性与可读性，将业务语义固化到数据库层，实现跨表规则复用、集中管理和一致性校验，避免应用层重复验证；例如用email、phone_zh等域替代普通TEXT类型，使字段含义明确，结合NOT NULL与DEFAULT强化完整性，通过嵌套CHECK组合基础域以应对扩展，但应避免过度创建导致维护负担，合理使用可让DDL真正承载业务契约。
PostgreSQL 的域（DOMAIN）类型是 SQL 标准支持的高级特性，它在基础数据类型之上封装约束和默认值，让建模更贴近业务语义。用得好，能显著提升表结构的严谨性、可读性和可维护性——不是“多此一举”，而是把校验逻辑从应用层前移到数据库层，避免重复、遗漏和不一致。
用域明确业务语义，替代模糊的基础类型
比如邮箱、手机号、国家代码、非空字符串等，若全用 TEXT 或 VARCHAR，表定义就失去业务含义。定义域后，字段名+类型本身就能传达意图：
- CREATE DOMAIN email AS TEXT CHECK (VALUE ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
- CREATE DOMAIN phone_zh AS TEXT CHECK (VALUE ~ '^1[3-9]\d{9}$');
- CREATE DOMAIN country_code AS CHAR(2) CHECK (VALUE ~ '^[A-Z]{2}$');
这样建表时直接引用：email_addr email，比 email_addr TEXT 更自解释，也强制所有使用该域的列遵守同一套规则。
集中管理约束，避免分散重复校验
多个表都需存储“有效正整数”或“ISO 8601 时间格式字符串”，若每个 CHECK 单独写，极易漏改、不统一。域把校验逻辑收口到一处：
- 修改邮箱正则？只改一次
DOMAIN email定义，所有依赖它的列自动生效（需ALTER DOMAIN ... VALIDATE CONSTRAINT触发检查）。 - 新增“仅限内部员工工号”字段？新建
DOMAIN emp_id_internal AS TEXT CHECK (VALUE ~ '^E\d{6}$')，复用即安全。
这比在 ORM 层写 validator 或在每个 INSERT/UPDATE 中拼 CHECK 更可靠、更易审计。
配合 DEFAULT 和 NOT NULL，强化数据完整性
域可自带默认值和非空约束，让“必填且有合理默认”的字段定义更紧凑：
- CREATE DOMAIN status_active AS TEXT NOT NULL DEFAULT 'active' CHECK (VALUE IN ('active', 'inactive', 'pending'));
- 建表时写
status status_active，无需再写DEFAULT 'active' NOT NULL，也不用担心某张表漏加 NOT NULL。
注意：域的 NOT NULL 是强约束（插入 NULL 直接报错），比列级 NOT NULL 更早拦截问题，且与 CHECK 同级执行，逻辑更清晰。
慎用继承式域，优先组合已有域与 CHECK
PostgreSQL 不支持域继承（如 CREATE DOMAIN non_empty_email AS email CHECK (LENGTH(VALUE) > 5)），但可通过嵌套 CHECK 实现类似效果：
- 推荐写法：
CREATE DOMAIN email_nonempty AS email CHECK (LENGTH(VALUE) > 5);—— 复用原域逻辑，再叠加新条件。 - 避免反模式：为每种微小变体（如 “带域名邮箱”、“公司邮箱”）都建独立域，导致域爆炸。应按业务稳定性分层：基础域（email）→ 场景域（work_email）→ 表级 CHECK（如
company_email CHECK (email ~ '@mycorp\.com$')）。
域不是越多越好，关键是覆盖高频、跨表、高风险的业务规则。
基本上就这些。域不是银弹，但它让 PostgreSQL 的 DDL 真正承载语义，把“程序员脑中的规则”变成“数据库执行的契约”。用得克制、定义清晰、团队共识，建模严谨度自然水涨船高。
