开发环境连错生产库是网络层和配置层双重失守，最有效防线是网段隔离：开发账号限定IP段、bind-address绑定127.0.0.1、防火墙禁止访问生产网段，确保路由层面不通才是硬边界。
开发环境连错生产库不是权限问题，是网络层和配置层双重失守。最有效的防线不是靠人眼核对 host，而是让 dev 根本连不上 prod 的网段。
MySQL 用户 host 不能只写 %
很多人用 CREATE USER 'app'@'%' IDENTIFIED BY 'pwd' 图省事，结果开发机一配错 host 就直连生产实例。% 允许任意 IP，包括你本机、测试机、CI 机器——只要路由可达，就可能误连。
- 开发账号必须限定为
'devuser'@'192.168.10.%'或'devuser'@'127.0.0.1'，禁止通配符 - 生产账号按实际服务网段精确授权，比如
'app_rw'@'10.20.30.0/24'，而不是'app_rw'@'%' - 执行
DROP USER IF EXISTS 'devuser'@'%'清理残留通配账号，防止覆盖更严格的规则
bind-address 和防火墙要双锁死
bind-address = 0.0.0.0 是生产库常见配置，但开发库绝不能这么开——它等于把 MySQL 暴露给整个局域网。开发环境应强制绑定 127.0.0.1，哪怕应用跑在 Docker 里也该用 host 网络或显式映射到 localhost。
- 开发机的
my.cnf中必须设bind-address = 127.0.0.1，重启后验证netstat -tlnp | grep :3306只监听本地 - 生产服务器防火墙（iptables / ufw / 云安全组）只放行指定内网段，如
10.20.30.0/24，严禁开放0.0.0.0/0 - 华为云等平台还有“跨网段访问配置”，需手动添加白名单网段，
127.0.0.0/8被明确禁止，别试图绕过
应用配置里 host 写 localhost 还是 127.0.0.1 很关键
MySQL 对 localhost 和 127.0.0.1 的处理完全不同：localhost 强制走 Unix socket，127.0.0.1 走 TCP。如果你开发配置写的是 localhost，但数据库账号是 'devuser'@'127.0.0.1'，连接直接失败——这不是 bug，是设计。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 开发环境统一用
host = localhost+'devuser'@'localhost'组合，避免 socket/TCP 混淆 - 生产环境必须用具体内网 IP（如
10.20.30.5），禁用localhost或127.0.0.1，否则容器或跳板机上会连错本地实例 - CI/CD 脚本里加校验：运行前执行
mysql -h $DB_HOST -u $DB_USER -e "SELECT DATABASE();"，若返回空库或报错，立刻中止
不同库名只是辅助，网段隔离才是硬边界
光靠 myapp_dev 和 myapp 两个库名防不住误操作。一旦开发账号有权限连上生产实例，DROP TABLE myapp.users; 照样执行。物理隔离必须靠网络层切断路径。
- 开发网段（如
192.168.10.0/24）和生产网段（如10.20.30.0/24）之间路由器/交换机 ACL 必须默认 deny - 云环境用 VPC 隔离，开发子网和生产子网不在同一路由表，不配对等连接
- 本地开发若用 Docker，宿主机防火墙要丢弃所有发往生产网段的 3306 包：
iptables -A OUTPUT -d 10.20.30.0/24 -p tcp --dport 3306 -j DROP
真正卡住误连的，从来不是 SQL 权限里的 GRANT，而是路由表里没有那条通往生产网段的下一跳。配置做完后，从开发机 ping 一下生产 DB IP，不通才是对的。
