要获取QT程序中服务器监听的端口号，核心方法是调用QTcpSocket和QTcpServer封装好的接口：服务端在listen()成功后用serverPort()读取，客户端在连接建立后用peerPort()读取。 这两步操作覆盖了绝大多数“需要知道端口号”的开发场景,也是我平时排查网络问题时最先印证的代码路径。
qt获取服务器端口号的方法有哪些
先把方法摆到台面上，便于你对照项目场景选型，常见的端口获取需求其实就两类：一类是自己写的服务端程序，想知道当前监听的是哪个端口；另一类是客户端程序，需要确认连上的服务器到底工作在哪个端口，两条路的代码都很短,但调用时机不对就会拿不到正确值。
服务端套路：listen成功之后立刻读端口
服务端代码里，端口号的获取依赖QTcpServer::serverPort()，这个方法返回quint16类型的端口值，前提是服务端已经成功进入监听状态,典型代码这样写：
QTcpServer server = new QTcpServer(this);
if (server->listen(QHostAddress::Any, 5566)) {
quint16 actualPort = server->serverPort();
qDebug() << "服务器已启动，监听端口：" << actualPort;
}
这里有个细节值得留意：listen()返回true之后再调用serverPort()，拿到的才是真实监听端口，如果你在listen()之前调用，得到的结果永远是0，这一点是新手最容易踩的空子，当参数里指定的端口号是0时，系统会自动分配一个空闲端口，serverPort()在这里就变成了“查询分配结果”的唯一途径。
客户端套路：连接成功后由peerPort带回服务器端口
客户端角度看服务器端口，走的是QTcpSocket::peerPort()，这个函数返回的是对端套接字的端口号，也就是服务端进程真正监听的端口，它跟peerAddress()是搭档，一个给IP，一个给端口,示例：
QTcpSocket socket = new QTcpSocket(this);
socket->connectToHost("192.168.1.10", 5566);
// 在connected信号槽里读取
connect(socket, &QTcpSocket::connected, this, [socket]() {
quint16 serverPort = socket->peerPort();
qDebug() << "已连接服务器，服务器端口：" << serverPort;
});
connected信号触发表示TCP握手已经完成，此时peerPort()的值是可靠的。连接没建立时调用peerPort()返回0，没有任何意义。
项目源码中到哪里去找端口设置
接手别人写的QT网络项目时，定位端口号的获取位置,可以按这个顺序排查：
- 搜索
listen(，看服务端入口函数,端口参数紧跟IP地址后面； - 搜索
connectToHost(,在客户端代码里确认目标服务器端口； - 搜索
serverPort()、localPort()、peerPort(),直接找到已经写好端口获取逻辑的代码块。
现在绝大多数XT网络模块都用信号槽异步处理，端口信息一般放在newConnection信号对应的槽函数里，顺着这个信号找，通常能看到服务端为每个客户端连接分配套接字的完整流程,端口获取的代码就藏在那附近。
qt tcp服务器查看客户端端口和服务器端口时的坑
不光是新手，很多写过一阵子网络代码的开发者，也会在端口获取上踩几个来回，我列几个高频场景,你可以对着自己的代码检查。
qt端口号获取不到是什么原因
端口拿不到，常见原因集中在调用时机、监听状态和对象指针这三件事上：
- 信号槽还没触发就取值，比如在
connectToHost()之后立刻调用peerPort()，此时连接还在建立中,端口信息自然为空。 - listen失败但没检查返回值，绑定的端口被占用、用户没有权限监听低位端口，都可能让listen悄悄失败，后续再调serverPort()拿到的是无效值。
- 误用了客户端的本地端口。
localPort()返回的是客户端本机随机分配的高位端口，跟服务器监听端口是两个概念,不少代码把这两个搞混了。
排查时记得在关键节点打印日志，把listen返回值、connected信号是否触发、peerPort()和localPort()的值全部输出,一眼就能看出问题在哪一环。
局域网qt服务器端口怎么确认
局域网环境下，服务器可能部署在另一台主机上，无法直接打开代码看端口，这时候，确认服务器端口的最快方式是在服务器本机执行网络查询命令，Windows下打开CMD,输入：
netstat -ano | findstr 5566Linux下面则用：
ss -tlnp | grep 5566命令输出里会明确列出监听该端口的进程PID，再配合任务管理器或ps命令，就能锁定是不是你的QT程序，这里有一个行业共识：排查网络问题时，先确认进程有没有监听端口，再怀疑代码逻辑，大多数端口获取不到的情况，其实在系统层面就能看到真相,网络抓包工具反而不是第一步需要动用的手段。
从需求角度说，局域网调试时，如果你知道服务器固定使用某个端口，那客户端直接填这个端口就行；如果服务器用了动态端口（端口为0），那必须有个机制把实际端口告诉客户端，通常是广播、配置文件或者中间的协调服务。动态端口场景下端口获取代码本身没错，但传递端口的通道往往被遗漏了。
动态分配端口与端口冲突处理
端口获取的意义，在动态分配场景下变得格外突出，你写服务端程序时指定端口为0，系统会自动挑选一个空闲端口供这次连接使用，这种设计在多实例部署时很受用,不需要担心端口互相撞车。
监听0端口动态分配的场景
服务端代码改成这样就行了：
if (server->listen(QHostAddress::Any, 0)) {
quint16 dynamicPort = server->serverPort();
// 把dynamicPort写入配置中心或打印出来
}
端口为0的写法在执行逻辑上和应用层无关，只是告诉操作系统“你来帮我选一个可用端口”，拿到的端口范围通常在1024到65535之间，具体数值由系统调度决定，这种模式适合快速搭建临时服务，特别是自动化测试脚本里，每个人跑的实例端口都不同,互不干扰。
端口冲突排查方式
端口绑定失败是服务端启动时最常见的错误之一，listen返回false之后，用server->errorString()能拿到具体的错误描述，如果是Address already in use，那就是端口被其他进程占用了,解决思路有三种：
- 换一个端口重新监听,最直接；
- 检查是否存在残留的旧进程,结束后再启动；
- 使用
SO_REUSEADDR选项，允许端口快速重绑,但要注意安全性。
接入层服务设计时，端口号通常做成配置文件里的参数，启动时从配置读入，而不是硬编码在源码里，这样一旦遇到端口冲突，改配置重启即可,不用重新编译整个项目。
不写代码也能查看端口号的排查方式
有些场景下，改代码去打印端口号成本太高，或者程序已经部署到现场不方便动手，这时直接靠系统命令定位端口，是更务实的路径，下面两张表分别对应Windows和Linux下常见的操作方式,方便你在不同环境里快速切换。
| 操作系统 | 命令 | 适用场景 |
|---|---|---|
| Windows | netstat -ano |
查看所有TCP连接与监听端口 |
| Windows | netstat -ano \| findstr 5566 |
精确查找某个端口 |
| Linux | ss -tlnp |
查看监听端口与进程信息 |
| Linux | lsof -i:5566 |
按端口号定位占用进程 |
| 通用网络调试助手 | 连接参数里的远端端口 | 验证客户端填写的端口是否正确 |
这些命令查出来的端口信息，可以和程序里serverPort()或peerPort()的结果相互印证，如果两边对不上，问题往往出在代码逻辑上,比如取端口时用了错误的socket对象。
相比另一个常用方案在程序里用QDebug输出端口值，系统命令的好处是不需要改动代码和重新编译，但只能看本机情况,无法显示其他主机上QT程序的监听结果。
Q&A：qt获取服务器端口号的常见问题
问：qt获取服务器端口号时serverPort返回0怎么办？
返回值是0，基本能确定服务端没有成功进入监听状态，检查listen的参数是否合法，端口是否被占用，监听地址是否绑定了错误的网卡，必要时调用errorString()查看具体失败原因。
问：qt客户端怎么拿到服务器指定的端口号？
连接建立之后，在最稳妥的位置调用peerPort()获取远程端口，如果项目里提前已知端口号，也可以直接用变量保存,不需要等到连接成功后再取。
问：服务器使用了动态端口（端口为0），客户端怎么知道端口号？
服务端必须把listen成功后serverPort()得到的值主动告知客户端，常见方式包括UDP广播、配置文件、数据库记录、或者通过第三方中间人服务传递，这个传输端口号的动作,本质上就是一套轻量级服务发现机制。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794886.html
