查npm启动的服务器端口号，最直接的方式是在终端执行netstat -ano | grep 端口号（Mac/Linux）或netstat -ano | findstr 端口号（Windows），配合lsof -i命令能精准定位进程，这是前端开发排查端口问题最常用的组合拳。
npm启动的服务器端口号怎么查：先分清你的运行环境
很多前端开发者在执行npm run dev或npm start后，终端窗口会直接打印出Local: http://localhost:5173这样的地址，但一旦终端滚动过快、日志被清空，或者你想确认某个端口是否真的被Node进程占用时，就需要手动去查，不同操作系统，对应的查询逻辑完全不同。
Windows系统：用netstat和findstr组合筛选
在Windows的CMD或PowerShell里,npm启动的Node服务本质是一个进程，它监听某个TCP端口，打开终端，输入以下命令就能看到所有活动端口列表：
netstat -ano这个命令会输出大量结果,直接看很容易眼花，所以我一般会配合findstr精确过滤，比如检查8080端口是否被占用：
netstat -ano | findstr :8080输出结果里会包含TCP和UDP的监听状态,最后一列就是进程ID（PID），如果看到LISTENING状态，说明端口正在被占用，如果结果为空，说明这个端口当前没有被Node服务监听，当你拿到PID后，还可以继续用tasklist | findstr PID号查看是哪个进程占用，确认是不是你刚启动的npm服务。
Mac和Linux系统：用lsof命令按名字直接搜
在macOS或Linux上,netstat虽然可用，但更推荐用lsof命令，因为lsof可以直接按进程名或端口号过滤，输出信息更友好，比如要查看8000端口被谁占用：
lsof -i :8000输出列表中COMMAND列会显示node，PID列显示进程号，NAME列会显示具体的IP和端口映射，如果你想看所有Node进程监听的端口，可以换成：
lsof -i -P | grep node这个命令会把所有Node服务监听的端口都列出来,特别适合本地同时跑多个npm项目的情况。lsof -i :端口号这个命令也常被用来排查“EADDRINUSE”报错也就是端口被占用的问题。
怎么查npm run dev时终端里没有显示端口号的情况
有些项目在启动配置时把日志输出做了精简,或者用了类似silent模式的启动参数，导致终端不打印访问地址，这时候需要去翻项目代码和配置文件，而不是干等。
查package.json里的scripts脚本设定
npm的启动脚本定义在package.json的scripts字段里，打开项目根目录的package.json，找到scripts对象，看dev或start对应的值，常见的写法有：
"dev": "vite --port 5173"显式指定端口"dev": "next dev -p 3000"指定Next.js端口"dev": "webpack serve --config webpack.dev.js"端口可能在webpack配置里
如果scripts里没有端口参数,就去查项目里的配置文件，比如Vite项目看vite.config.js（可能有server.port配置），React项目看.env文件里的PORT变量，Node原生项目看代码里的app.listen(3000, ...)。
用Node命令直接执行一段代码查监听端口
如果你还是找不到端口在哪配置,可以在项目目录下打开终端，用Node执行一段内联脚本，列出当前Node进程正在监听的端口：
node -e "const net = require('net'); const server = net.createServer(); server.listen(0, () => { console.log('当前空闲端口：', server.address().port); server.close(); })"不过这条命令是找一个空闲端口,不是查已启动的端口，更实用的方式是，先执行npm run dev启动服务，然后不要关终端，直接在另一个终端窗口跑node -e "console.log(process.env.PORT || '未设置环境变量PORT')"，确认是不是环境变量在起作用，多数框架默认端口有规律，比如Vite默认5173，Webpack默认8080，Next.js默认3000，Create React App默认3000，这些都属于行业共识。
npm run dev端口号被占用怎么解决：从查找到清理的完整流程
开发过程中最常见的场景不是不知道端口号,而是端口被占用导致启动失败，你运行npm start时终端往往会把具体报错信息打出来，比如Port 8080 is already in use或者
EADDRINUSE: address already in use :::5173，这时候需要一步步处理。
精确查找到PID并终止进程
第一步,用上面提到的方法找到占用端口的PID，Windows用户执行netstat -ano | findstr :8080，Mac/Linux用户执行lsof -i tcp:8080，拿到PID后，执行以下命令杀掉进程：
- Windows：
taskkill /PID 具体的数字 /F - Mac/Linux：
kill -9 具体的数字
执行完毕后,重新执行npm run dev，服务就能正常起来了，需要留意的是，Mac系统上有时lsof输出的PID是系统进程或别的开发者工具占用的，强杀前建议确认下COMMAND列是不是node或其他可信进程。
换个端口重新启动npm服务
如果项目允许,另一种更快的解法是直接换个端口启动，比如React项目的传统做法是在package.json的start脚本里改成"start": "set PORT=3001 && react-scripts start"（Windows写法），Mac/Linux下则是"start": "PORT=3001 react-scripts start"，对于Vite项目，可以直接在终端执行：
npm run dev -- --port 3001命令行传参的优先级通常高于配置文件,多数情况下能直接生效，如果你不想每次启动都手动指定端口，可以在环境变量里预设，从业务角度看，前端项目保留多个端口配置也方便联调时同时跑两个环境对比效果。
查端口遇到特殊情况的排查技巧
有两个容易让人困惑的场景：一是npm服务启动成功但外网访问不了，二是端口能访问但不知道对应的是哪个服务，这时候需要结合进程名和PID进一步确认。
从进程名反查PID并定位监听端口
如果你知道服务是Node进程,但不知道它监听哪个端口，可以用lsof -i -P | grep node（Mac/Linux）一次性列全，Windows下则先执行tasklist | findstr node.exe拿到所有Node进程的PID，再逐个用netstat -ano | findstr 对应PID去匹配监听状态的行，这种方法对排查“后端服务起来了但端口和前端预计的不一致”这种问题特别有效。
注意IPv4和IPv6地址的区别
netstat输出结果里，LISTENING状态的行可能同时存在IPv4地址（
0.0.0:3000）和IPv6地址（[::]:3000），这通常意味着Node服务在同时监听两种网络协议栈，当浏览器访问localhost:3000时，可能会优先走IPv6解析，如果你在云服务器上部署，外网访问不通但本地curl正常，大概率就是监听地址设成了0.0.1而不是0.0.0，查看端口时别只看监听状态，也要看Local Address这一列绑定的IP。
为什么推荐先查端口再启动npm服务
与其等启动报错再排查,不如在启动前就养成检查端口的习惯，业内专家指出，前端开发中相当一部分启动失败案例都和端口冲突有关，尤其是在多个项目并行开发时，我个人的操作习惯是：每天打开电脑后先执行netstat或lsof看下常用端口（3000、5173、8080）有没有被残留进程占用，再启动npm服务，这个习惯看似多了一步操作，实则能省下不少定位报错的时间。
从工具本身的逻辑看,npm本身不管理端口，端口绑定是框架或Node底层http模块干的活，所以问题核心始终是：谁在监听你想要的端口，掌握了这一点，无论前端项目用Vite、Webpack还是Next.js，排查思路都是通用的。
Q&A：与npm查看服务器端口相关的常见疑问
问：npm run dev启动后，终端显示端口号变化了，为什么会自动换端口？
答：当配置的端口号已被占用时，部分现代构建工具（如Vite）会自动尝试下一个可用端口，所以你会看到5174代替了5173，这是工具内置的防冲突机制，如果你不希望端口被自动切换，可以在配置里设置server.strictPort: true，这样端口被占用时会直接报错而不是自动换端口。
问：npm start和npm run dev查看端口的方法有区别吗？
答：没有本质区别，两者都是启动Node进程，底层监听机制相同，因此查看端口的方式完全一致：用netstat或lsof按端口查进程，或者到配置文件和脚本里找端口参数，区别仅在运行模式，比如npm start常用于生产或预发布环境，npm run dev常用于开发热更新环境，但这不影响端口的查询方式。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/667149.html
