AGE函数返回interval类型而非整数年份，如AGE('2025-04-01','2000-05-15')得“24 years 10 mons 17 days”；不可直接与整数比较，需用EXTRACT(YEAR FROM ...)提取年份，但不处理月份进位；判断满18周岁应改用birth_date + INTERVAL '18 years'。
AGE函数返回的是interval类型，不是整数年份
PostgreSQL的AGE函数本质是做日期减法，结果是interval（时间间隔），不是“多少岁”这种整数。比如AGE('2025-04-01', '2000-05-15')返回24 years 10 mons 17 days，不能直接用于WHERE条件比较或GROUP BY分组。
常见错误是写成WHERE AGE(birth_date) > 18——这会报错，因为interval无法和整数直接比较。
- 要提取完整年份，必须配合
EXTRACT(YEAR FROM ...)，但注意：它只取interval中的year字段，不考虑月份进位（例如17 years 11 mons仍被算作17） - 若需“满18周岁”的业务逻辑，应改用
birth_date + INTERVAL '18 years' -
AGE()有两个签名：AGE(timestamp)（计算从该时间到当前时刻的差）和AGE(timestamp, timestamp)（两时间相减），别混淆参数顺序
用EXTRACT(YEAR FROM AGE())有精度陷阱
很多人用EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date))想快速得年龄，但这个值在生日当天才更新，其余时间都偏小。比如某人出生于2000-03-15，到2025-03-14时，AGE返回24 years 11 mons 30 days，EXTRACT(YEAR FROM ...)仍返回24；到2025-03-15才跳到25。
这不是bug，是interval设计使然——它保留了原始月份/天数结构，不自动规整为“总年数”。
- 如果只要粗略年份（如统计报表），这个方式可接受
- 如果用于权限控制、资格校验（如“必须年满18”），必须用日期比较：
birth_date - 注意时区：所有参与
AGE的timestamp最好统一为timestamptz，避免因本地时区导致跨日偏差
替代方案：用CURRENT_DATE - birth_date再除以365.25更不准
有人尝试(CURRENT_DATE - birth_date) / 365.25转成年份，这是危险操作。PostgreSQL中两个date相减得到的是整数天数（integer），除法结果是numeric，但365.25只是平均值，无法处理闰年、2月天数浮动、以及“是否已过生日”这类逻辑。
- 2000-02-29出生的人，在2024-02-28时实际未满24周岁，但该公式会算出≈23.999，向下取整变23，错误
- 数据库不会帮你做“生日判断”，它只做数值运算
- 真正健壮的做法永远是：把年龄判断转回日期比较，而不是把日期转成数字再比
生产环境建议直接用日期偏移判断
绝大多数需要“年龄≥N”的场景，根本不需要算出具体数字。用birth_date 既准确、又走索引（如果<code>birth_date有索引）、还规避了所有interval解析歧义。
- 例如查18岁以上用户：
WHERE birth_date - 要查“正好18岁零3个月”，写成
birth_date = CURRENT_DATE - INTERVAL '18 years 3 months' - 如果非得输出整数年龄列供前端展示，再用
EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date))，但别拿它做条件
真正难的不是怎么调用AGE，而是意识到：数据库里“年龄”不是属性，而是依赖当前日期的动态计算结果；把它固化成数字，就埋下了逻辑漂移的隐患。
