PostgreSQL 里藏着一对冷门的 GUC（Grand Unified Configuration）参数：bonjour 和 bonjour_name。它们让数据库在局域网里自动广播自己的存在——客户端零配置就能发现服务器。听起来很美好，但这个基于 Apple Bonjour/mDNS 协议的设计，诞生于 2002 年，放到今天的网络环境下，弊远大于利。
Bonjour 广播做了什么
启用 bonjour 后，PostgreSQL 的 postmaster 进程会在启动时通过 mDNS（multicast DNS，RFC 6762）向局域网注册一条服务记录。协议类型固定为 _postgresql._tcp。bonjour_name 则控制这条记录的显示名称，默认取主机名。
客户端只要支持 Bonjour 发现，就能在"可用数据库"列表里看到这台服务器，无需手工填写 IP 和端口。
配置方式非常简单，在 postgresql.conf 里加两行：
# postgresql.conf
bonjour = on
bonjour_name = 'dev-pg-primary'
重启 PostgreSQL 即生效。可以用 dns-sd 命令行工具验证广播是否成功：
# macOS 自带 dns-sd；Linux 可安装 avahi-utils
dns-sd -B _postgresql._tcp local.
# 发现后查询详情
dns-sd -L dev-pg-primary _postgresql._tcp local.
输出里会看到端口、主机名等信息——这就是客户端"零配置发现"的全部机制。
为什么 2002 年这是个好主意
那年局域网还是主流工作场景：办公室里几台 Mac 共享一台数据库服务器，开发者不想每次换机器都改连接字符串。Apple 的 Rendezvous（后来改名 Bonjour）正在推广"零配置网络"理念，PostgreSQL 顺势接入，体验确实顺滑——打开 pgAdmin，服务器自动出现，点一下就连上了。
在封闭、可信的局域网里，mDNS 广播的便利性是真实的。
为什么今天不该再开它
四个原因，每一个都足以让你把 bonjour 设成 off。
安全暴露。 mDNS 广播是向整个局域网无差别推送服务记录。任何同一子网的设备都能看到你的 PostgreSQL 实例——包括攻击者的笔记本、被入侵的 IoT 设备、隔壁团队的容器。数据库服务本该最小化可见性，Bonjour 做的恰恰相反。
云和 VPC 环境不兼容。 AWS、GCP、Azure 的 VPC 子网默认不转发多播包。mDNS 在云环境里根本走不通。你的 RDS 或 EC2 上的 PostgreSQL 开了 bonjour 也只是白占一个启动步骤，没有任何客户端能收到广播。
IPv6 和复杂网络的麻烦。 mDNS 在 IPv6 双栈网络里的行为容易出歧义——同一主机可能注册多条记录，客户端解析到错误地址。现代 Kubernetes 集群、Docker 网络里多播路由更是默认关闭的。
维护负担。 这对参数在 PostgreSQL 代码树里占着专门的 hook 和初始化逻辑，但实际使用率极低。社区多次讨论过是否移除，目前只是标记为不建议启用。留在配置里只会增加新用户的困惑。
实际检查与关闭
如果你在维护一个继承来的 PostgreSQL 集群，值得确认 Bonjour 是否被意外开启：
# 查看当前运行值
psql -c "SHOW bonjour;"
psql -c "SHOW bonjour_name;"
# 如果返回 on，立刻在 postgresql.conf 中关闭
# bonjour = off
# 也可以用 ALTER SYSTEM（PostgreSQL 9.4+）一次性修改
psql -c "ALTER SYSTEM SET bonjour = off;"
psql -c "SELECT pg_reload_conf();"
注意：bonjour 是 postmaster 级参数，pg_reload_conf() 不能切换它的状态——必须完全重启 PostgreSQL：
# Debian/Ubuntu 系统用 pg_ctlcluster
pg_ctlcluster 16 main restart
# 通用方式
pg_ctl -D /var/lib/postgresql/16/main restart
替代方案：现代的服务发现思路
关闭 Bonjour 不意味着放弃便利。现代环境里有更合适的做法：
| 场景 | 替代方案 |
|---|---|
| 开发环境多实例 | 连接字符串写进 .env 或 pg_service.conf，版本化管理 |
| Kubernetes 集群内 | Service + DNS（pg-primary.namespace.svc.cluster.local），天然可发现 |
| 跨团队共享 | 内部 DNS 注册或 Consul/service mesh，带健康检查和权限控制 |
| 临时调试 | pg_isready -h <host> 验证可达性，比广播安全得多 |
pg_service.conf 是一个容易被忽略的 PostgreSQL 原生功能，它让你把连接参数命名分组，客户端只需引用服务名：
# ~/.pg_service.conf（或 $PGSYSCONFDIR/pg_service.conf）
[dev-primary]
host=10.0.1.50
port=5432
dbname=app_dev
user=app_user
[staging]
host=10.0.2.100
port=5432
dbname=app_staging
# 连接时只写服务名
psql service=dev-primary
# Python psycopg2 也支持
# import psycopg2
# conn = psycopg2.connect("service=dev-primary")
这比 Bonjour 广播更可控：配置可以提交到 git、可以区分环境、不会泄露到不该看到的子网。
关掉它，用更现代的方式发现服务
bonjour 和 bonjour_name 是 PostgreSQL 历史里一个有趣的脚印——2002 年的零配置愿景确实优雅，但今天的网络环境已经完全不同：多播被云网络屏蔽、安全模型要求最小暴露、服务发现有了更精细的工具。开启这对参数只会增加暴露面和维护困惑，不会带来实际便利。
检查你的 postgresql.conf，把 bonjour 设为 off，然后用 pg_service.conf、DNS 或 Consul 做服务发现——这才是 2024 年该有的做法。