Mac多网卡下服务不可访问的根源是监听地址与客户端子网不匹配、路由路径错误或防火墙拦截，而非端口冲突；应检查lsof确认监听地址（127.0.0.1/0.0.0.0/具体IP），确保客户端与Mac在同一子网，并配置防火墙放行。
mac 开发端口本身不会“冲突”，真正出问题的是你启动的服务（比如 localhost:3000、127.0.0.1:8080 或绑定到 0.0.0.0:5000 的本地服务）在多网卡环境下被错误地访问或无法访问——根源不在端口，而在系统如何把入站请求路由到你的服务，以及你的服务监听地址是否匹配实际网络路径。
确认服务监听地址是否“暴露过度”或“过于封闭”
开发服务默认绑定 127.0.0.1 或 localhost 时，只响应本机回环请求，和多网卡无关；但一旦改用 0.0.0.0 或具体局域网 IP（如 192.168.1.10），就进入路由决策环节：
-
绑定
0.0.0.0：服务接受所有接口的连接，但客户端能否连上，取决于对方是否能路由到你当前对外广播的 IP —— 而这个 IP 所属的网卡，可能不是你预期的那个（比如 Wi-Fi 和有线都开着，但调试手机连的是有线网段，而你的手机其实连着 Wi-Fi） -
绑定具体 IP（如
192.168.1.10）：服务只监听该 IP 对应的网卡。若该网卡断开、IP 变更，或客户端从另一网段发起请求（如通过 USB 网络共享连进来的设备），就会连接拒绝 -
检查方式：终端运行
lsof -iTCP -sTCP:LISTEN -P | grep :3000，看 LISTEN 列显示的是*:3000（即0.0.0.0:3000）、127.0.0.1:3000还是某个具体局域网地址
排查客户端访问失败的真实路径
你以为“连不上开发服务器”，其实是请求根本没走到 Mac 上。关键要看客户端和 Mac 之间走的是哪条链路：
- 用手机扫码调试？确认手机和 Mac 是否在同一子网（比如都是
192.168.1.x）。如果 Mac 同时连 Wi-Fi（192.168.1.10）和有线（10.0.0.5），而手机连的是 Wi-Fi，那必须确保服务监听192.168.1.10或0.0.0.0，且防火墙放行该端口 - 用同事电脑访问？先
ping你的 Mac 局域网 IP。不通，说明不是端口问题，而是路由/ARP/防火墙层面阻断 - Mac 自己
curl http://192.168.1.10:3000成功，但手机 curl 失败 → 检查 macOS 防火墙是否允许“来自不信任网络的连接”（系统设置 > 隐私与安全性 > 防火墙 > 防火墙选项）
避免因多网卡导致服务“不可见”的实操建议
不依赖系统自动选网卡，主动控制服务可见范围：
- 开发阶段优先绑定
0.0.0.0，而非某个具体局域网 IP；这样无论 Wi-Fi、有线、甚至虚拟网卡（如 Docker、VMware）分配了什么 IP，只要在对应子网内都能访问 - 如需限制访问范围（例如只允公司内网），可配合
pfctl写简易防火墙规则，而不是靠绑定特定 IP 来“隐藏” - 若使用
ngrok、localtunnel或 VS Code Remote Tunnel，它们会绕过多网卡路由逻辑，直接建隧道，适合跨网络调试 - 遇到“有时能连有时不能”，大概率是 macOS 默认路由切换导致 ARP 表混乱或服务监听网卡临时失活，此时执行
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder清理即可，无需重启服务
本质上，这不是端口冲突，而是网络可达性管理问题。盯住监听地址、客户端子网、防火墙三者是否对齐，比纠结“哪个网卡优先”更高效。
