简介：《软件工程实习记录》是一份面向本科软件工程专业学生的实习文档，适用于正在完成暑期实习、毕业实习或需要整理实习日志与报告的人群，可为记录实习过程、梳理项目任务和撰写总结提供参考。压缩包内共1个doc文件，约40KB，内容按周组织，覆盖软件开发的主要流程、需求与设计步骤、项目经理职责、常见岗位分工及前后端技术栈等知识点。文档结合具体实习任务展开，涉及Eclipse Swing界面与文件查找排序功能、HTML/CSS/JavaScript页面制作、Node.js与Express请求响应、MySQL数据导入及增删改查，以及Linux与ARM开发环境配置等实践内容。目前已有2924人学习，读者可据此了解实习记录的写法、任务拆解方式和总结角度，并结合自身经历修改成适用的实习材料。

1. 那些报错比流程更值钱：一份软件工程实习记录里的十几个坑

翻自己大学期间那份软件工程实习记录，最有信息量的部分不是开头工整抄下的六步开发流程，而是后半本里一句句“今天卡住了”。IIS 装完网页打不开、Tomcat 一访问就弹 500、数据库装到一半回滚退出、中文录进去变成问号、项目部署上去端口又被别的服务占了——这些当年耗掉半天甚至一整晚的问题，几乎每一届写实习记录、做毕业设计的人都会原样再撞一遍。我把这份实习记录按故障类型拆开重排了一遍，每个报错都写清触发条件、根因和能照着敲的操作，遇到哪条直接跳到对应章节。

2. 本地站点打不开：IIS 装完却提示无法查看网页，权限层才是真凶

2.1 现象：服务在跑、端口没错，页面就是不出来

典型场景是这样的：在本地虚拟机上装好系统，装上 IIS 组件，把默认网站的主目录指到项目所在文件夹，地址栏输入网址回车，等了几十秒，浏览器只给一句“无法查看网页”。第一反应当然是服务没起来，于是去服务列表看 W3SVC，明明在运行；怀疑端口冲突，把 80 换成 8080，照样打不开；索性把防火墙整个关掉，还是没有变化。

到这一步人就容易发慌了，因为“服务在跑 + 端口没冲突 + 防火墙关了”这三个条件凑在一起，直觉会把方向指向网络层，而真正卡住的地方在文件系统权限层。更麻烦的是它不给你 403，也不给 404，就是干巴巴一句打不开，连个错误码都不留，排查时很容易顺着错误的线索一路改配置，改到最后自己都不知道改了哪些。

这类问题在本地建站、内网发布、把项目从开发机搬到测试机的过程中出现频率极高。新手会以为是 IIS 没装对，老手会先去看日志，但日志默认也是关的，得手动开。所以第一步不是改配置，是把现象固定下来：确认服务状态、确认站点状态、确认日志位置，三件事做完再动手。

2.2 根因：IIS 不是用你的账号去读目录的

IIS 的工作进程读取站点文件时，用的不是当前登录的桌面账户，而是一个专门的低权限账户。老系统上叫 Internet 来宾账户，新系统上是 IIS_IUSRS 组和 IUSR 账户。这是刻意设计的安全隔离：网站代码即使被攻破，也只能拿到这个低权限身份，碰不到系统其他部分。

问题就出在这里。你把自己建的文件夹指给 IIS 当主目录，这个文件夹的访问控制列表里只有你自己的账户和 Administrators 组，来宾账户根本不在名单上。IIS 去读 index.html，系统回一句“拒绝访问”，IIS 把这个拒绝包装一下返回给浏览器，最终呈现出来的就是“无法查看网页”。所以现象看起来是网络问题，实际是 NT AUTHORITY 层面的授权问题。

还有一层容易被忽略：权限设置的入口本身可能是隐藏的。文件夹属性里的“安全”选项卡，只有当所在分区是 NTFS 格式时才会出现；如果分区是 FAT32，你翻遍属性页也找不到安全这一页，于是误判成“这个系统没有权限可设”。很多人就是在这里绕了远路，最后靠重装系统格式化分区才解决，代价太大了。

第三层是权限粒度。只给读权限，静态页面能打开，但只要后台需要上传图片、写日志、改配置文件，就会在保存那一刻失败。这类失败往往报在业务代码里，日志写的是“文件写入失败”，跟权限八竿子打不着，又得多排查一轮。所以一次性把读和执行、修改两类权限都规划好，比事后补要省事。

2.3 解决：分两步补齐权限与默认文档

先说权限。图形界面的路径是：右键站点目录 → 属性 → 安全 → 编辑 → 添加 → 输入IIS_IUSRS→ 确定 → 勾选“读取和执行”“列出文件夹内容”“读取”；如果站点有后台管理或文件上传需求，再勾上“修改”。老系统上账户名是IUSR_计算机名，输入时注意别漏了下划线后面的机器名。

命令行更快，尤其在要批量处理多个站点目录时：

:: 给 IIS 工作进程账户授予站点目录的读取与执行权限 :: (OI) 表示对象继承，(CI) 表示容器继承，/T 表示递归到所有子目录 icacls "D:\sites\demo" /grant "IIS_IUSRS:(OI)(CI)(RX)" /T :: 站点需要上传、写配置、生成缓存时，追加修改权限 icacls "D:\sites\demo" /grant "IIS_IUSRS:(OI)(CI)(M)" /T :: 回读一遍，确认授权条目真的写进去了 icacls "D:\sites\demo"

参数含义值得拆开说清楚，因为写错一个括号权限就白给了：/grant是追加授权，不会覆盖已有条目；(OI)让权限对目录下的文件生效，(CI)让权限对子目录生效，两个都写才能覆盖整棵树；RX是读取和执行，M是修改，F是完全控制，日常建站给到M已经足够，不要图省事直接上F。/T会递归处理已有文件，新加的文件靠继承规则自动生效。

权限通了之后还有第二个坑：默认文档。IIS 默认只认Default.htm、Default.asp、index.htm、iisstart.htm这几个名字，你的首页如果叫index.jsp或者default.aspx，访问根路径时 IIS 找不到入口，要么报 403.14（目录列表被拒），要么直接列出文件目录。常见做法是在站点的“默认文档”列表里把index.jsp、index.html、default.aspx依次加进去，顺序按项目实际入口排。

第三步是打开日志，这是本地建站最该养成的一个习惯。IIS 日志默认在C:\inetpub\logs\LogFiles\W3SVC1下，按天切分。日志里那一列sc-status是判断层级的钥匙：

看到 401.3 就不用再折腾端口和防火墙了，直接回去看权限；看到 403.14 就去看默认文档；看到 500 说明请求已经进到应用里了，问题在代码层，这时候该换方向。

2.4 验证：用两个动作把结论钉死

改完权限别急着开首页，先放一个纯静态文件试水。在站点目录下新建test.html，内容随便写一行文字，浏览器访问对应的 URL。静态页能打开，说明 IIS 服务、端口、目录权限三层全部通了，剩下的问题一定在应用层；静态页打不开，就还是回到权限或默认文档上，不要往代码里找。

第二个动作是日志验证。清空当天日志，刷新一次页面，立刻去看新增的那一行，sc-status和sc-substatus一起读。有些问题会连续报两行，第一行是被拒的原始请求，第二行是 IIS 重定向后的结果，只看最后一行会被误导。

提示：站点目录尽量统一放在D:\sites这类短路径、纯英文、无空格的目录下。桌面、文档、用户目录这些位置带有额外的继承权限和用户账户控制干扰，出了问题很难剥离变量。

3. Tomcat 弹 500 且日志写着数据加载失败：先别动配置文件

3.1 500 只是外壳，真正的话在 localhost 日志里

Java Web 项目部署到 Tomcat 后，浏览器一打开就吐HTTP Status 500 - Internal Server Error，页面上干干净净，连异常栈都不给。这时候最典型的错误动作是去改server.xml：端口改一遍、Context路径改一遍、web.xml也顺手改一遍，重启十几轮，500 还是 500。

500 这个状态码的含义是“服务器内部处理请求时出错了”，它已经越过了连接建立、请求解析、路由映射这几层，说明请求确实进了应用。所以端口、连接器配置、防火墙这些跟它没关系。真正要看的第一个地方是日志目录下的catalina.out和按日期切分的localhost.yyyy-mm-dd.log，那里才有完整的异常栈。

我一般会按时间顺序先捞最近一次请求的异常，而不是从头读启动日志：

# 直接抓最近的异常栈，-A 30 表示连带打印后面 30 行 tail -n 300 logs/catalina.out | grep -A 30 "Exception" # 当天日志里第一个 ERROR 往往就是根因，后面的多是连锁反应 grep -n "ERROR\|Exception" logs/localhost.$(date +%Y-%m-%d).log | head -20

命令里-A 30的 30 不是固定值，栈深了往上加；head -20是为了避免一次刷屏几百行把关键信息顶掉。日志里如果出现“数据加载失败”这类自定义提示，说明异常被catch住了，并且被重新包装成一个业务语义的字符串——根因就在这个catch块的上游，栈里往下找Caused by。

3.2 根因：驱动 jar 和数据库版本对不上，报出来的却是连接失败

顺着栈往下看，经常能看到SQLException或者ClassNotFoundException。这时候很多人第一反应是数据库没启动、账号密码错了、网络不通，于是去ping、去telnet端口、去重装数据库，一圈折腾下来发现数据库本身好好的。

真正的根因往往是驱动包和数据库大版本不匹配。比如数据库是较老的版本，驱动却是新版的，两者在协议握手阶段对不上，DriverManager.getConnection直接抛异常；或者反过来，驱动太老、服务端启用了新的认证方式，连接同样失败。表现出来的都是“连不上”，但跟网络和账号一点关系都没有。

还有一个更隐蔽的版本：WEB-INF/lib下放了一份驱动，Tomcat 自己的lib目录下也放了一份，两份版本不同。应用类加载器会按双亲委派规则先往上找，最终实际生效的那一份可能不是你放进去的那一份。这种问题最折磨人，因为你在项目里怎么看都是对的，实际跑的却是另一个包。

第三个常见问题是异常被吞。原始代码把SQLException捕获后只打印一句“数据加载失败”，栈信息彻底丢失，于是排查者只能从现象反推。这个坑不是技术问题，是日志习惯问题，但它能让一次五分钟的定位变成一晚上。

3.3 排查与修复：四步把版本和连接钉死

第一步，把实际加载的驱动路径打出来，别靠猜：

// 连接前先确认三件事：驱动类能否加载、jar 从哪个目录来、版本号是多少 Class<?> driver = Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver"); System.out.println("driver loaded from: " + driver.getProtectionDomain().getCodeSource().getLocation()); System.out.println("driver version: " + driver.getPackage().getImplementationVersion()); // 连接串里显式写超时，失败要快速暴露，不能挂在那儿等 String url = "jdbc:sqlserver://127.0.0.1:1433;" + "databaseName=demo;loginTimeout=5;encrypt=false"; try (Connection conn = DriverManager.getConnection(url, "app", "******")) { // 打印服务端版本，和驱动版本对照着看，是否大版本对齐 System.out.println("server: " + conn.getMetaData().getDatabaseProductVersion()); } catch (SQLException e) { e.printStackTrace(); // 完整栈必须落日志 throw e; // 原始异常继续往外抛，别包成业务提示 }

getCodeSource().getLocation()打印的是 jar 的真实物理路径，一眼就能看出是不是被 Tomcat 的lib目录抢先加载了；getImplementationVersion()依赖 jar 包清单文件里有没有写版本信息，返回null说明这个包是裁剪过的，本身就有风险；loginTimeout=5让连接失败在 5 秒内暴露，而不是默认超时挂几分钟让人以为程序卡死；encrypt=false只建议在本地或内网测试环境用，生产环境该开就开。

第二步，清掉重复的驱动包。原则是只保留一份，要么放WEB-INF/lib跟着应用走，要么放 Tomcat 的lib供多应用共享，两者选一。改完必须停服务、清work目录缓存、再启动，否则旧的类还在内存里。

第三步，核对连接串里的实例信息。默认实例走 1433，命名实例需要在连接串里额外声明实例名，否则连上去会被拒绝，报出来的同样是连接失败。这一步在把项目从开发机搬到另一台数据库服务器时特别容易漏。

第四步，改代码里的异常处理。catch块里至少打印完整栈，最好把原始异常继续往上抛，让上层统一处理。日志里只有一句“数据加载失败”的代码，等于给自己埋了一颗定时炸弹。

3.4 一个判断技巧：先分清是“连不上”还是“连上了但取不到”

这两类问题的排查路径完全不同。判断方法很简单：把连接单独拿出来测一次，能拿到Connection对象就是连上了，问题在 SQL 语句、表名、字段名或者结果集映射；连Connection都拿不到，才去查驱动、端口、账号。

这一步用一段二十行的独立测试类就能完成，不需要启动整个 Web 应用。很多团队的做法是先跑一遍连接测试再部署，能省掉大量“部署完才发现连不上”的往返。

注意：任何涉及数据库连接的报错，第一步永远是拿到原始异常栈。包装过的业务提示只适合展示给最终用户，不适合给开发者看。

4. 数据库装不上、中文存不进：安装选项和字符集这两处最容易翻车

4.1 装到一半回滚退出：不是环境问题，是安装类型选错了

现象很固定：安装程序跑到配置服务那一步突然报错，进度条回滚，提示安装失败；卸载重装，还是同一个位置失败；换安装路径、关掉杀毒软件、用管理员身份运行，全都无效。反复几次之后，人开始怀疑系统版本、怀疑安装包损坏。

实际的根因往往在第一步就埋下了：安装类型选了默认的“典型”模式，没有进自定义列表勾选开发者相关组件。典型模式为了减小体积，只装运行时需要的部分，开发所需的头文件、库文件、命令行工具都不在包里，后续初始化服务或者启动实例时找不到依赖，初始化就失败了。表现成“安装到一半报错”，很容易被误判成环境不兼容。

正确的做法是从卸载残留开始，一步一步来，不要在原状态上反复重试：

1. 卸载已安装的实例，手动删除数据目录和配置文件目录，确认服务列表里没有残留服务；
2. 以管理员身份运行安装程序，不要双击直接跑；
3. 安装类型选“自定义”，在组件列表里把开发者相关选项勾上；
4. 数据目录路径用纯英文、无空格、无中文，避开系统盘；
5. 设置 root 密码时避开特殊字符，避免命令行登录时被 shell 转义；
6. 安装完成后先别急着建库，先用命令行验证一次。

:: 确认服务是否注册成功、当前状态是什么 sc query MySQL :: 尝试启动，失败时这里会给出具体错误码 net start MySQL :: 登录并顺手看一眼字符集配置，确认实例可用 mysql -u root -p -e "show variables like 'character_set%';"

sc query看的是服务注册状态，如果没有输出说明服务根本没建上，问题还在安装阶段；net start失败时给出的错误码往往比安装界面的提示更具体，去查这个错误码比盲目重装有效得多；最后那条show variables不只是验证登录，还能提前发现字符集是不是默认值，为后面 4.2 节埋的坑做预警。

4.2 中文变成问号：连接层没声明字符集，数据在传输时就丢了

现象是英文和数字一切正常，中文录进去查出来全是???。这类问题的可怕之处在于不可逆——变成问号之后，原始字符信息已经丢失，再怎么改配置也救不回来，只能重新录入。

根因在连接层。客户端和服务端握手时会协商一个字符集，如果客户端没显式声明，驱动可能按默认编码发送，服务端按自己的字符集解析，两边的映射表对不上，转换失败就降级成问号。注意这里说的不是“存进去之后显示乱码”，而是“存进去的时候就已经是问号了”，两者排查方向完全不同。

解决办法是把字符集在三个位置都写死，不要依赖任何默认值。第一个位置是建库建表：

-- 建库时显式指定字符集，别用默认值，默认值在不同版本里并不一致 CREATE DATABASE bookshop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 建表时再声明一次，避免继承到意外的库级默认 CREATE TABLE book ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL, author VARCHAR(60) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

utf8mb4和utf8的区别值得单独说一句：前者是完整的四字节实现，能存生僻字和表情符号；后者在很多版本里只有三字节，遇到四字节字符会直接报错或者截断。新项目没有兼容包袱，直接用utf8mb4。COLLATE决定排序和比较规则，同一张表里的字段不要混用不同排序规则，否则关联查询时会报排序规则冲突。

第二个位置是连接串：

// useUnicode 开启字符转换，characterEncoding 声明客户端编码 // serverTimezone 在新版驱动里是必需的，缺失会直接抛异常 String url = "jdbc:mysql://127.0.0.1:3306/bookshop" + "?useUnicode=true" + "&characterEncoding=utf8" + "&serverTimezone=Asia/Shanghai";

useUnicode=true只是开关，真正决定编码的是characterEncoding，两个要一起写；serverTimezone不是可选项，新版驱动在时区无法确定时会拒绝建立连接，报的错还跟字符集没关系，容易误导。

第三个位置是服务端配置，也就是配置文件里的默认字符集。改完必须重启服务才生效，只改配置文件不重启是无效操作。

4.3 页面回显还是乱码：页面编码和库编码是两回事

还有一种情况：用命令行客户端查数据库，中文显示得好好的，说明存储没问题；一到页面上就是乱码。这时候不要再回去改数据库了，问题出在输出链路上。

根因是页面没声明编码，容器按默认编码（很多老版本默认 ISO-8859-1）把字符写给浏览器，浏览器又按另一套规则解析，自然对不上。解决办法是在页面头部把响应编码和页面编码同时写死，两个都要写，只写一个在某些容器上仍然会乱：

<%-- pageEncoding 管 JSP 源文件本身怎么读，contentType 管响应怎么写给浏览器 --%> <%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>

如果是表单提交上来的数据乱码，问题在请求侧，需要在读取参数之前设置请求编码：

// 顺序很关键：必须在 getParameter 之前调用，之后再设已经晚了 request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8"); response.setContentType("text/html;charset=UTF-8"); String title = request.getParameter("title"); // 此时取出来才是正确的

setCharacterEncoding只对请求体有效，对 URL 查询参数无效，后者取决于容器配置。所以带中文的查询参数尽量走 POST，或者在容器层面统一配置 URI 编码。

顺便说一句，当年那份记录里最终是把数据库和页面编码统一改成gbk解决的，思路完全正确——关键不是选哪个编码，而是所有环节选同一个。现在新建项目直接用utf8mb4就行，别在新项目里引入gbk。

4.4 三个位置对齐的检查顺序

遇到乱码别乱改，按固定顺序查一遍，五分钟能定位到具体环节：

从上往下走，第一个出问题的位置就是根因所在。不要在四个位置上同时改，那样即使好了也不知道是哪一步起的作用，下次遇到照样抓瞎。

5. 避坑清单：端口占用、路径写死、重复渲染这五个坑最耗时间

5.1 端口被占用：改了配置还是起不来

现象：项目打包放进服务器目录，启动脚本跑完没报错，浏览器访问却是连接被拒绝；或者启动日志里明明白白写着端口绑定失败，服务根本没起来。

原因通常有两个。一是默认端口被别的进程占了，同一台机器上装了多个中间件、或者上次的服务没停干净，都会撞车。二是改了配置文件却没生效——改的是server.xml，但启动用的是另一份配置；或者改完没重启，进程还在用旧配置跑。

# Linux 下确认端口到底被谁占着，最后一列是进程号 netstat -tulnp | grep 8080 # Windows 下等价写法 netstat -ano | findstr :8080 # 拿到进程号后反查是什么程序 ps -ef | grep <PID>

解决方式是把Connector的port改成一个没被占用的端口，同时确认redirectPort不要和别的连接器冲突：

<!-- 改端口只需改 port，但改完必须整包重启，热部署不会重新绑定 --> <Connector port="89" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

connectionTimeout是连接超时毫秒数，默认 20 秒对小项目足够；redirectPort是 HTTPS 重定向端口，如果你没配 SSL 连接器，这个值改成任意不冲突的端口即可。改完访问地址也要跟着变，http://localhost:89/项目名/，端口漏写会直接连不上，别以为是没启动。

5.2 项目放进目录却访问不到：上下文路径没对上

现象：项目整个文件夹拷进webapps，重启服务，浏览器打开根路径是 404 或者一个空白欢迎页。

原因几乎都是上下文路径的锅。部署到webapps下的项目，默认访问路径是http://主机:端口/文件夹名/，不是根路径。如果文件夹叫bookshop，地址就得是/bookshop/index.jsp。想直接走根路径，要么把文件夹名改成ROOT，要么在配置里显式声明上下文为空。

另外两个容易忽略的点：文件夹名的大小写必须和 URL 完全一致，Linux 上路径区分大小写，Windows 上不区分，本地测通搬到服务器就 404，八成是这个原因；还有work目录里的编译缓存，改了 JSP 但页面没变化时，先清这个目录再重启。

5.3 查找功能只能查固定目录：根路径被写死在代码里

现象：输入框输文件名能查出来，但永远只查得到某一台机器上某一个文件夹里的东西，换台电脑或者换个盘符就一条都搜不到。

原因很直白：查找的根目录被硬编码在代码里了。当时那份记录里就是这个问题，本地调试时图省事写死了绝对路径，功能演示没问题，一交付就废。正确的做法是把根路径抽成配置项，运行时递归遍历，同时处理没有权限访问的目录，不能让一个NullPointerException把整次查询打断。

// root 从配置文件读取，不要写死在代码里 public List<File> search(File dir, String keyword, List<File> result) { File[] files = dir.listFiles(); // 没有权限或是空目录时 listFiles 返回 null，必须判空，否则直接 NPE if (files == null) { return result; } for (File f : files) { if (f.isDirectory()) { search(f, keyword, result); // 递归进子目录 } else if (f.getName().contains(keyword)) { result.add(f); // contains 实现模糊匹配 } } return result; }

listFiles()返回null是这段代码最容易翻车的地方，系统目录、回收站、其他用户的目录都可能返回null，不判空就会在遍历到一半时崩掉。contains做的是子串匹配，对应需求里的模糊查找；如果要忽略大小写，两边统一转小写再比。递归深度大时建议加个层数上限，避免符号链接成环导致无限递归。

5.4 添加一条数据，页面上出现两条

现象：点一次添加按钮，表格里多出两行一样的记录，或者反复点几次之后数据成倍增长。

原因分前后端两种。前端的原因是每次都往原有容器里追加节点，没有先清空，历史渲染结果一直留在 DOM 里；后端的原因是查询结果本身带了重复数据，比如关联查询没去重，或者上一次的临时数据没清。

前端的修法很简单，渲染之前先清空容器，再统一插入：

// 渲染前必须清空，否则历史结果会不断叠加 function render(list) { const tbody = document.querySelector("#teacherTable tbody"); tbody.innerHTML = ""; // 先清空，这一步不能省 const frag = document.createDocumentFragment(); // 批量插入，减少重排 list.forEach(item => { const tr = document.createElement("tr"); tr.innerHTML = `<td>${item.id}</td><td>${item.name}</td><td>${item.course}</td>`; frag.appendChild(tr); }); tbody.appendChild(frag); // 一次性挂到页面上 }

innerHTML = ""清空的是子节点，容器本身还在，比重新创建整个表格轻；DocumentFragment是离屏节点，循环里往它上面挂不会触发页面重排，最后一次性插入，数据量大时差别很明显。如果记录里出现了重复数据而不是重复渲染，那要回去查 SQL 有没有漏DISTINCT或者关联条件写错。

5.5 静态数组换数据库：先定返回结构，再改渲染

现象：页面用数组渲染时一切正常，一接数据库就白屏，控制台报undefined或者Cannot read property of undefined。

原因是数据来源换了，但渲染函数的假设没变。原本数组里的对象字段叫name，数据库查出来映射成了teacher_name，渲染时取不到就崩。异步请求还多了一层时序问题：数据还没回来就执行了渲染。

稳妥的顺序是反过来的：先把接口返回的 JSON 结构定死，写一个假数据版本把渲染函数调通，再接真实数据库，最后删掉假数据。这样任何一次失败都能明确归因到“是数据结构变了”还是“是网络请求失败了”，而不是对着一片白屏猜。

注意：这几个坑的共同点是“本地演示没问题，一换环境就出事”。凡是硬编码的路径、端口、字段名，交付前都该过一遍配置化检查。

6. 快速定位：十分钟把“打不开”缩到一个具体层

排查这类问题最耗时间的不是解决，而是不知道自己在哪一层。我后来固定用一个从外往内的顺序，基本十分钟内能把范围缩到某一层，剩下的就是那一层内部的细节。

第一层，服务在不在。netstat看端口有没有监听，服务列表看进程状态。端口没监听，后面的全都不用看，直接去查启动日志。第二层，请求到没到。看访问日志里有没有这次请求的记录，有记录说明网络和端口都通，问题在应用内；没记录说明请求根本没进来。第三层，应用报没报错。看应用日志里的异常栈，抓第一个ERROR而不是最后一个。第四层，数据通不通。单独跑一次连接测试，能把“连不上”和“连上了取不到”分开。第五层，编码对不对。用命令行客户端直接查，能区分是存储问题还是输出问题。

这五层的判断依据可以压成一张表，遇到报错先对号入座：

用这张表的时候有个习惯要养成：一次只改一个变量。很多人一着急就同时改端口、改编码、改权限，结果好了也不知道是哪一步起的作用，下次照样抓瞎。我自己的做法是改之前先把当前配置备份一份，改完立刻验证，验证不通过就回滚再换下一个假设，绝不在一个已经改乱的环境上继续叠加改动。

还有一个习惯值得强调：把“能复现”当成排查的前提。报错如果只是偶发，先想办法让它稳定复现，再做定位。当年那个 500 的问题之所以拖了一整天，就是因为一开始没去翻日志，而是在配置文件上反复试错，试到最后连哪次改动有效都说不清了。

从那以后我每次遇到“打不开”这三个字，都强制自己先走一遍服务、日志、数据、编码这四步，不管多急都不跳步。跳过的那一步，最后一定会以双倍时间还回来。希望帮到你。

本文还有配套的精品资源，点击获取