简介：这份《软件工程实习记录》面向本科软件工程及相关专业学生，尤其适合需要撰写实习周记、整理项目实践材料或准备毕业实习归档的读者参考与改写。压缩包共1个doc文件，约40KB，以按周记录的Word文档形式呈现，内容从实习动员、分组开发延伸到具体任务实现，可按时间线直接借鉴结构与表述。文档结合真实项目场景梳理软件开发六步流程、需求与设计要点、项目经理职责、常见岗位及前后端技术栈，并记录Swing文件查找与排序、HTML/CSS/JavaScript页面、Node.js接口、MySQL增删改查、Linux与ARM环境搭建等实践片段，便于读者理解开发流程、补充实习记录细节并对照修改。目前已有2924人学习，适合作为实习记录模板与软件工程实践复盘参考。

1. 写代码只占 15%：一份四周实习记录里最反直觉的一句话

四周实习结束的那天晚上，我把这份按日期一条条记下来的软件工程实习记录从头翻了一遍。第一天的笔记里写着一句当时自己都不太信的话：编码在整个开发过程里大概只占百分之十五。这是大学毕业前那段实习留下的原始材料，从可行性分析、需求分析一路记到最后一晚的 Tomcat 部署，中间夹着一堆当天就出问题、当场修改的操作。

它能帮到三种人：正在补实习记录、需要一份能照着改的骨架的人；刚上手 Java Web、天天在环境和编码上卡住的初学者；以及想知道企业里一个功能从需求到上线要经过几道处理环节的人。我按时间线拆开讲，哪些是当天就有结论的，哪些是半年后才想明白的，哪些问题其实到现在还有人天天踩。能复现的步骤，命令和参数我都写出来。

2. 桌面工具与静态页：第一周的功能为什么都卡在「地址写死」上

第一周的任务看着很小：做个文件查找、做个文件排序、做个教师信息展示页。三件事没有一个用到框架，全是 JavaSE 加 HTML/CSS/JS。但正是这一周让我第一次意识到，能跑起来和能用之间隔着的不是语法，而是「变量从哪来」这件事。当时的代码里到处是写死的路径、写死的数组、写死的字段名，功能演示没问题，换个目录就报错，换个数据源就得重写。

回过头看，这一周的价值不在于我写了几个控件，而在于它把三类最基础的问题摊开了：文件系统怎么访问、排序按什么规则算「有序」、页面数据从哪来。这三件事在后面 Node.js 单页和 JSP 阶段会以另一种形式重新出现，只是那时候你会用框架把它包起来，看不见底层。

2.1 文件查找功能：从写死路径到让用户选目录

当年的第一版是这样的：在面板上放一个输入框、一个按钮、一个表格，点击后去某个固定盘符下扫一遍，把包含关键字的文件名回显到表格里。演示能过，但只要换台机器就完蛋，因为路径写在了代码里。我拿着这个问题去问驻场的指导工程师，他改了两处：路径改成由文件选择器返回，回显前先清空表格。改动很小，但把「参数」这个概念讲透了——凡是会变的东西都不该硬编码在方法体里。

复现的核心代码大概长这样：

// 查找面板：关键字来自输入框，根目录来自文件选择器，两者都不写死 JFileChooser chooser = new JFileChooser(); chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY); // 只允许选目录，避免用户选到文件 if (chooser.showOpenDialog(panel) == JFileChooser.APPROVE_OPTION) { File dir = chooser.getSelectedFile(); String keyword = keywordField.getText().trim().toLowerCase(); // listFiles 只扫一层，模糊匹配用 contains，忽略大小写 File[] hits = dir.listFiles((d, name) -> name.toLowerCase().contains(keyword)); tableModel.setRowCount(0); // 关键：先清空，否则每次查找结果会叠加 if (hits != null) { for (File f : hits) { tableModel.addRow(new Object[]{f.getName(), f.length(), new Date(f.lastModified())}); } } }

setFileSelectionMode决定用户能选什么，这是最容易漏的一行，漏了用户就会选到一个文件，listFiles返回 null，界面直接空白，看起来像「查找没生效」。listFiles传的是过滤器，只做一层扫描；要递归得自己写FileVisitor，而且必须考虑权限不足的目录会抛异常。还有一个当时完全没意识到的点：扫描放在事件线程里，目录一大界面就假死，正确做法是丢进SwingWorker，边扫边往表格里加行。

提示：文件名模糊匹配不等于数据库里的 like。后者的大小写敏感性取决于字段的排序规则，同一个关键字在两边可能给出不同结果，测试时别只测小写目录。

这一小节真正该带走的是判断依据：什么时候用文件选择器、什么时候用配置项。选目录这种由使用者每次决定的东西，必须走交互；而像根目录这种部署环境固定的东西，更适合放配置文件。当年我把两者混在一起，所以每次换机器都得改代码重新编译，这就是典型的把配置写进了逻辑里。

2.2 冒泡排序给文件名排序：当年的选择和今天的替代方案

第二天的任务是「把磁盘里现存的文件按文件名排序」。记录里写的是冒泡排序，说实话当年选它不是因为合适，而是因为它是唯一一个我能不看资料默写出来的。冒泡在几十条数据上完全够用，但文件列表动辄上千条，O(n²)的比较次数会让界面明显卡顿，而且它对字符串的处理默认是字典序，file10会排在file2前面，用户一眼就觉得「排错了」。

三种常见做法的对比，我一般这么比：

实际工程里没人手写排序，直接用库函数加比较器：

// 用库函数替掉手写冒泡，比较器决定「什么算有序」 Arrays.sort(files, (a, b) -> a.getName().compareToIgnoreCase(b.getName())); // 想要 file2 排在 file10 前面，就得抽数字做自然序比较，而不是纯字典序 Comparator<File> natural = (a, b) -> { String x = a.getName().replaceAll("\\d+", m -> String.format("%010d", Long.parseLong(m))); String y = b.getName().replaceAll("\\d+", m -> String.format("%010d", Long.parseLong(m))); return x.compareToIgnoreCase(y); };

第一段是字典序，第二段把名字里的数字补零到固定宽度再比，这样2会被补成0000000002，自然就排在10前面。参数上唯一要盯的是大小写策略：Windows 的文件系统不区分大小写，Linux 区分，同一份排序代码在两个平台上结果可能不同，跨平台工具必须显式指定compareToIgnoreCase或者统一转小写。

注意：排序结果依赖比较器，不依赖排序算法本身。换个算法但不换比较器，用户看到的顺序不会变，所以排查「排序不对」永远先看比较器。

这一段判断依据很清楚：数据结构小、只求正确，手写没问题；一旦数据量上来或者要和界面的其它逻辑配合，就用库函数加比较器，把「有序的定义」抽出来单独维护。后来做报表导出时我用的是同一个思路，排序规则抽成配置，前端后端共用一套，省掉了很多「为什么两边顺序不一样」的争论。

2.3 数组渲染表格：前端第一步不是样式，是数据从哪来

第一周最后一天是用 HTML 标签加 CSS 加 JavaScript 做一个教师信息展示页，数据先放在数组里，用表格渲染出来。当时我以为难点在样式，实际卡住的地方是「页面怎么知道数组里有什么」。写完才发现这套东西只能演示静态数据，真实项目里数据在数据库里，页面得先发请求、拿到响应、再拼 DOM，这三步任何一步错了，页面上就是一片空白。

这就是为什么后面必然要走到 Node.js 单页和 JSP：不是技术栈升级，是数据源从内存换成了数据库之后，请求、响应、渲染这条链必须显式建立起来。很多人在这一步以为是前端框架的问题，其实是没搞清楚请求发给了谁、返回了什么格式。判断依据很简单——如果刷新页面数据就没了，那数据在内存里；如果换了浏览器数据还在，才说明数据落了库。

3. 从静态数组到 MySQL：Node.js 单页这条最朴素的链路

第二周开始接触 Node.js。目标写得很清楚：实现一个单页，把数据库里的教师信息读出来显示，再支持增删改查。听上去是一个完整的 CRUD，实际上被拆成了三步：先让页面能发请求、再让服务端能连数据库、最后让按钮触发不同的 SQL。这个拆分方式后来我一直在用，因为它把「玄学问题」变成了三段可单独验证的链路——前端错了就查请求，服务端错了就查连接，数据错了就查语句。

这段经历里最值钱的不是 Express，而是「先用静态数组跑通，再换真实数据源」这个顺序。当年我不理解为什么不能直接连库，多绕了一圈；现在带人时我会强制要求这么干，因为一旦请求链路没通，你就分不清是接口没写对还是数据库连不上，两个变量同时存在，排查成本翻倍。

3.1 npm init 之后的两小时：Express 的 get 与 post 最小闭环

搭建过程很朴素：装 Node.js，桌面建一个目录当根目录，npm init初始化，生成package.json，然后装 Express。当年为了搞懂 get 和 post 花了小半天，现在回头看，只需要记住一点：get 的参数在 URL 上，post 的参数在请求体里，而请求体要能被解析出来，中间必须挂一个解析中间件。

const express = require('express'); const app = express(); app.use(express.urlencoded({ extended: true })); // 解析表单体，没有这行 post 拿到的 req.body 是 undefined // 过渡阶段：先用内存数组验证「请求-响应」这条链路是通的 let teachers = [{ id: 1, name: 'A', course: '数据结构' }]; app.get('/api/teachers', (req, res) => { res.json(teachers); }); app.post('/api/teachers', (req, res) => { const { id, name, course } = req.body; // 字段名必须和页面 input 的 name 完全一致 teachers.push({ id, name, course }); res.json({ ok: true, count: teachers.length }); }); app.listen(3000, () => console.log('listening on 3000'));

express.urlencoded的extended决定嵌套对象怎么解析，表单场景用 true 兼容性更好。字段名对齐是最常见的出错点：页面写teacherName，后端解构name，请求能通、响应 200，但数据库里全是空值，这种问题不看请求体根本查不出来。至于app.listen的端口，选 3000 只是习惯，被占用时 Node 会直接抛EADDRINUSE，改成 3001 就行，不用改其它任何东西。

提示：用浏览器地址栏直接敲接口地址只能测 get，测 post 得用curl或者页面表单，很多人以为接口挂了，其实是没发对方法。

判断依据在这里也很明确：如果只是取数据，用 get，参数少且不敏感；一旦涉及写入、删改，一律 post。当年我把删除做成了 get 链接，刷新页面就重复删一次，这个坑在第 5 章会再提。

3.2 Excel 进 MySQL：建库、建表、字符集三件事

数据从 Excel 导进数据库，听上去是体力活，实际上是整条链路上最容易埋雷的一步。当年我按顺序做了三件事：装数据库、建库建表、把 Excel 里的数据导进去。中间卡住的地方全在字符集上：Excel 默认的编码、建表时指定的字符集、连接时声明的字符集，这三个只要有一个对不上，导进去的中文就是问号或者乱码。

-- 建表时显式指定字符集，别依赖服务器默认值 CREATE TABLE teacher ( id INT PRIMARY KEY, name VARCHAR(32) NOT NULL, course VARCHAR(64) NOT NULL ) DEFAULT CHARSET = utf8mb4;

utf8mb4和utf8的区别在于能不能存四字节字符，业务上只要有可能出现特殊符号就选前者。建表不写字符集时，表会继承库的默认值，库又继承服务器的默认值，一路继承下来，不同机器上装出来的结果可能不一样，这就是为什么同样的建表语句在同事电脑上正常、在我电脑上乱码。

数据导入之后，用 Node 读出来还得过一道 JSON 转换。这里的参数是连接配置，四个字段一个都不能错：

const mysql = require('mysql'); const pool = mysql.createPool({ host: '127.0.0.1', user: 'app_user', // 别用 root 跑业务代码，权限太大 password: '******', database: 'school', charset: 'utf8mb4' // 连接字符集，缺了这一步前面建表的字符集白设 });

用连接池而不是单连接，是因为每次请求新建连接的开销在并发下很明显。charset这一项最容易漏，漏了之后表里的数据是对的，查出来的 JSON 却是乱码，排查时容易误判成前端问题。判断依据：如果数据库客户端里查出来正常、接口返回乱码，问题一定在连接层；如果客户端里就是乱码，问题在写入或建表。

3.3 增删改查的真实结构：四个按钮背后是四条函数链

页面上的增删改查看着是四个按钮，做起来是四条链路：按钮点击 → 触发某个 JS 函数 → 发请求到对应路由 → 执行某条 SQL → 返回结果 → 重新渲染。当年我做完发现「添加」有个毛病：同一条信息点两次就出现两条，页面越点越乱。解决方式是在添加前先清空原来的回显，再重新拉一遍列表。这个改法很土，但当时的场景下够用——它至少让页面状态和服务端状态重新对齐了。

真正值得记下来的是这四条链路的分工。查询是只读的，失败了不影响数据；新增和修改要先校验再写库；删除是最危险的，必须有二次确认。当年删除做成了 get 超链接，浏览器预加载或者用户刷新都会再发一次请求，重复删除不会报错但会让人以为「数据自己没了」。正确做法是删除走 post 或 delete，且服务端做幂等处理——删不存在的 id 返回成功而不是 500。

判断依据：任何会改数据的操作都不能用 get。这条到现在我 review 代码时还在查，看到<a href="/delete?id=3">一律打回。至于渲染方式，当年是手动拼 DOM，现在更常见的是拿到 JSON 后交给模板或者前端框架，本质没变：数据流是单向的，服务端返回什么，页面就显示什么，不要在页面里自己造数据。

4. 环境与部署这两关：Linux、服务器、Tomcat 全踩一遍

第三周开始事情变得不友好了。前面写的都是应用层的代码，错了看日志能猜个八九不离十；这一周碰的是操作系统、编译工具链、Web 服务器，出问题时现象和原因之间隔着好几层，属于典型的黑匣子。我那几天最大的感受是：环境问题的排查顺序比技术细节重要得多，顺序对了能少走一半弯路。

这一周的四块内容是连着的——先在一台企业版 Linux 上跑通编译和部署流程，再回头搞懂网络服务器在局域网里扮演什么角色，然后是本地网站的权限配置，最后是 Tomcat 上的端口和依赖。当年我是按任务顺序硬着头皮做完的，现在回看，其实应该反过来：先建立「请求从浏览器到进程经过哪些层」的模型，再去动具体的配置文件。

4.1 ARM-Linux 环境验证：hello.c 加 Makefile 到底在验证什么

第一个任务是熟悉 Linux 环境：建目录、写hello.c、写Makefile、编译、把编好的文件放到开发板上跑。当年只觉得这是走流程，后来才明白这几步验证的是四件不同的事：交叉编译工具链是否装对、头文件路径是否正确、构建脚本能否复现、产物能否在目标架构上执行。

# 最简构建脚本：目标、依赖、命令三段式 hello: hello.c gcc hello.c -o hello clean: rm -f hello

Makefile 的规则是「目标 : 依赖」，下一行必须是 Tab 缩进而不是空格，这是新手第一个高频翻车点，报错信息是missing separator，看不出哪里错。clean目标不是给构建用的，是给「重来一次」用的，删掉产物再编一遍，能排除掉「改了源码但跑的还是旧二进制」这种低级问题。

如果目标是 ARM 开发板，编译器就不是gcc而是带前缀的交叉编译器，产物用file hello一看架构就知道对不对——这一步比在板子上跑起来更早发现问题。判断依据：编译通过只能说明语法和头文件没问题，file看架构、ldd看动态库依赖，两个都过了才算环境真的通了。

注意：交叉编译出来的程序在开发机上直接执行会报「无法执行二进制文件」，这是正常的，不是编译失败。

这一段后来对我的影响很大：任何新环境，我都先跑一个最小可执行程序，而不是直接上项目。最小程序能通，说明工具链、路径、权限这几层没问题，剩下的错误就只可能出在业务代码里。这个习惯省下的时间，比任何调试技巧都多。

4.2 本机网站打不开：IIS 来宾账户权限与 NTFS 格式

参与公司网站制作时，我的任务是在本地装环境、配 IIS、设默认站点的主目录。系统装完了，IIS 组件装了，主目录也指过去了，浏览器一访问就是打不开。查了半天资料才发现是两个原因叠在一起：本地虚拟访问需要给 Internet 来宾账户配读取权限，而权限选项卡只有在 NTFS 格式的磁盘上才显示。

这件事的教训不是「记住勾哪个框」，而是理解 IIS 的工作方式：它用一个低权限账户去读站点目录，这个账户没有权限，页面就返回 401 或者 403。很多人看到「无法查看网页」第一反应是站点没启动或者端口不对，实际上状态码已经区分开了——401/403 是权限，404 是路径，500 是应用内部错误。当年我连状态码都没看，直接去改配置，纯属乱试。

第二个坑更隐蔽：磁盘格式决定你能不能看到安全选项卡。FAT 格式没有 ACL 概念，自然也没有权限设置入口。判断依据很直接——如果「属性」里根本找不到「安全」页签，先看磁盘格式，别去翻 IIS 配置。这条经验后来在服务器上复用：给应用分配目录时，第一件事是确认文件系统支持权限模型，否则后面所有的权限设计都是空谈。

权限给到「读取」还是「修改」，取决于这个目录要不要被程序写入。当时因为后续要做后台管理，需要上传文件，所以勾了修改权限。这个决定有代价：上传目录可写，就意味着如果有人传了可执行文件并想办法访问到，风险很高。正确做法是把上传目录单独拎出来，禁掉脚本执行权限，这是后来做安全评审时才补上的认知。

4.3 端口占用与 jar 版本不匹配：两封日志的读法

最后一周做部署，遇到了两个经典问题，它们共同的特点是：现象和原因隔得很远，不看日志永远猜不到。

第一个是 Tomcat 起不来，访问项目主页失败。翻日志发现配置的端口已经被别的进程占用。端口冲突的表现有时候不是启动报错，而是启动"成功"但访问不通，因为请求被另一个进程接走了。查占用的命令两个平台不一样：

netstat -ano | findstr :8080 # Windows：最后一列是进程号，拿去任务管理器对 ss -lntp | grep 8080 # Linux：直接能看到进程名和 pid

改端口只要动server.xml里的 Connector 配置，把 8080 换成 89 之类没被占用的即可。但要注意，改完端口后项目里如果写死了回调地址或者前端请求地址，也得跟着改，否则页面能打开、接口全 404。判断依据：能打开静态页但接口报错，先查地址里的端口，别急着怀疑后端。

第二个是 Java 网站在浏览器里报 500，服务端日志里有一句「数据加载失败」。当时第一反应是 Tomcat 配置有问题，改了一堆连接池参数都没用，最后发现是驱动 jar 包和数据库版本不匹配，连接根本建立不起来。这个问题的排查顺序应该是：先看日志里最内层的那条异常，ClassNotFound是驱动没引入，No suitable driver是驱动和连接串协议不匹配，通信异常才是网络或版本兼容问题。

提示：日志要从最下面往上读，最内层的Caused by才是根因，上面那些只是层层包装。

这两个问题让我形成了一个固定动作：任何环境问题，先确认「进程在不在、端口通不通、依赖版本对不对」，三样都过了再去改配置。这个顺序看起来笨，但它把不确定性一层层剥掉了，比漫无目的地改参数快得多。

4.4 分层框架与 JSP：为什么学完还是不会独立做项目

第三、四周穿插着学了 Struts、Spring、Hibernate 和 JSP。当时的理解是三个框架分别管三层：表示层、业务逻辑层、持久层，这样分工是为了让不同岗位的人写出来的代码风格一致，同时把一些重复代码自动生成，省掉手写 JDBC 和 SQL 的活。这个理解不算错，但不够用，因为它只回答了「它们是什么」，没回答「什么时候该用哪一层」。

真正卡住我的是另一件事：学完这些概念，我依然没法独立做一个项目。原因现在看很清楚——我学的是分层的结果，没学分层的动机。比如为什么要用 ORM，是因为手写 JDBC 时「打开连接、拼 SQL、处理结果集、关资源」这四步每次都要重复，且关资源的顺序错了会泄漏连接；ORM 把这些封装掉，代价是你要理解它生成的 SQL 长什么样，否则慢查询查不出来源。

JSP 也是同理。当时的理解是「在页面里嵌 Java 代码片段，就能动态生成内容，还降低了对浏览器的要求」。这个说法本身没错，但它掩盖了真正的问题：逻辑写在页面上，改一个判断就要动模板，测试也没法单独测。后来所谓的分层，本质是把「取数据」「算逻辑」「渲染」拆开，让每一层能单独改、单独测。

判断依据：如果一个功能改起来要同时动三个文件，说明分层没做对；如果改一个展示文案都要重新编译，说明逻辑和视图耦合了。当年我以「能跑」为标准，所以永远停留在能跑的水平。这个认知转变发生得很晚，但它比任何一个框架的用法都重要。

5. 踩坑排查：四周里最耗时间的五个问题

下面这五个问题，是那四周里真正吃掉时间的。共同点是现象都具有误导性，第一反应基本都是错的。我按「现象 → 原因 → 解决」的格式记下来，顺序按当时踩到的先后排。

5.1 数据库装不上：安装向导里被跳过的「开发者」选项

现象：安装程序跑到一半就退出，没有任何明确报错，重装两遍结果一样，换安装包也不行。

原因：安装向导里有一步是选安装类型，默认选项装出来的是一套精简配置，缺了开发需要的组件和管理工具。我一路点「下一步」，根本没看那一页写的是什么。

解决：卸载残留、清掉数据目录，重新跑安装向导，在选择安装类型那一步显式选开发者模式，后面的组件全装上。判断依据是：如果安装过程「太顺」，反而要警惕是不是用了默认精简配置。后来我装任何开发环境都习惯先看安装向导有几步、每步选了什么，这个动作花不了一分钟，但能省掉两小时。

5.2 中文乱码：三个字符集只要有一个不一致就出问题

现象：往数据库里插中文，用客户端查是问号，从接口读出来是乱码，页面显示又是一堆方块。

原因：Excel 文件的编码、建表时表用的字符集、连接字符串里声明的字符集，三处不一致。当年只改了页面编码，所以页面上的乱码没了，库里的数据还是错的。

解决：三处统一到utf8mb4——建表时显式写DEFAULT CHARSET，连接配置里写charset，导入数据时确认源文件编码。排查顺序是从后往前：先在数据库客户端里直接查，客户端里就乱说明写入环节错了；客户端正常但接口乱，说明是连接层；两者都正常只有页面乱，才是页面渲染的问题。这个顺序能把范围一次缩到三分之一。

5.3 添加的信息重复显示：页面状态没和服务端对齐

现象：同一个教师信息点两次添加，页面上出现两条，刷新后又变回一条。

原因：添加成功后前端没重新拉列表，而是直接在本地数组里又 push 了一条，页面显示的是本地累积的结果，服务端其实只有一条。当年的土办法是「添加前先清空原来的回显」，本质就是用重新渲染代替增量更新。

解决：写操作之后一律重新拉一次列表，用服务端返回的数据覆盖本地状态。代价是多一次请求，好处是永远不会出现「页面和服务端不一致」。判断依据：如果刷新页面数据就正常了，那问题一定在前端状态管理，不在后端。

5.4 Tomcat 启动后访问失败：端口被占用

现象：启动脚本没报错，浏览器访问就是打不开，换浏览器、清缓存都没用。

原因：配置的端口已经被另一个进程占用，请求被那个进程接走了。这种冲突有时不体现在启动日志里，所以看起来像「服务起来了但没响应」。

解决：用netstat或ss查端口占用，改server.xml里的 Connector 端口，同时把前端请求地址、回调地址里的端口一起改掉。改完先用curl直接请求一个静态资源验证服务器本身通了，再去测接口。判断依据：静态资源能拿到、接口 404，就是应用内路径问题；静态资源也拿不到，才是服务器层问题。

5.5 500 错误与「数据加载失败」：驱动 jar 包版本不匹配

现象：页面报 500，日志里只有一句数据加载失败，改连接池参数、改 Tomcat 配置都没有效果。

原因：数据库驱动 jar 包和数据库版本不匹配，连接压根没建立起来。日志里真正的根因藏在最内层的Caused by里，被外层异常盖住了。

解决：从日志最底部往上读，找到最内层异常。驱动类找不到就补 jar 包，驱动不适用就换对应版本的驱动，通信异常才去看网络和端口。判断依据：所有「连不上数据库」的问题，先分清楚是「找不到驱动」「驱动不认协议」还是「网络不通」，这三类的修法完全不同，混在一起改只会越改越乱。

6. 把四周记录整理成能复用的模板：一张表加一个排查顺序

这份记录最后能直接用，靠的不是文笔，是结构。我当时是按天流水账记的，回头整理时才发现，真正有价值的信息只有四列：今天做了什么、卡在哪、根因是什么、对应哪个知识点。按这个结构重排之后，它既是一份实习记录，也是一份自己的问题库。

填这张表时有个技巧：卡点那列一定要抄原始报错，不要自己转述成「数据库连不上」。原始报错是唯一能搜到答案的东西，转述过的描述搜索命中率极低。根因那列如果当时没搞清楚，就写「未确认」，别硬编一个，编出来的错误结论比空白危害大得多。

排查顺序也固定下来了：进程在不在 → 端口通不通 → 字符集对不对 → 依赖版本匹不匹配 → 权限够不够。这五步覆盖了那四周里八成的问题，而且顺序是从外到内，每一步都能把范围砍掉一块。看起来是笨办法，但它不依赖灵感，谁都能照着走一遍。

从那以后我每接一个新环境，都强制自己先跑一遍这个顺序，哪怕一切正常也跑，因为「正常」本身就是一条要记录下来的基线。有了基线，下次出问题时才知道是哪一步变的。这份记录里那些当天看起来很蠢的操作，恰恰是后来最常被翻回去看的部分。希望帮到你。

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