问问题是门技术活。问得好,同事愿意帮你;问得差,同事嫌你烦。这节讲怎么高效地问问题,既不丢人又能快速解决。
一、先说大实话
新人不敢问问题
很多新人怕暴露自己水平不行,遇到问题死磕,一卡就是半天一天。
正确的态度: 入职前3个月,问问题是天经地义的。没有人指望你什么都懂。但怎么问、什么时候问,有讲究。
但也别什么问题都问
该自己先搞定的:
- 百度能搜到的
- 项目文档里写了的
- 前几天刚问过的
- 报错信息里已经说明白的
该问的:
- 项目业务逻辑(只有内部人知道)
- 公司技术规范和约定
- 搞了2小时以上还没解决的
- 涉及多个模块的问题
二、问问题前先做什么
1. 先搜索
按以下顺序找答案:
- 看项目文档 — README、wiki、Confluence
- 看代码注释 — 很多问题代码里写了
- 看Git历史 —
git log或 IDEA的Annotate功能 - 百度/Google — 报错信息直接搜
- 看同事的代码 — 类似功能别人怎么实现的
- Stack Overflow — 技术问题的最佳答案库
2. 记录你已经试过的
问之前先记录:
- 你想做什么
- 报了什么错
- 你已经试了什么方法
- 哪些方法不管用
这样别人帮你时不用从头排查。
3. 准备好上下文
- 截图报错信息
- 复制完整的错误堆栈
- 标注你改了哪些文件
- 如果方便,准备好复现步骤
三、问问题的标准格式
烂的问法
TEXT
"在吗?"
"有个问题想问一下"
"我的项目跑不起来了"
"报错了你帮我看看"
问题:
- 没说具体什么问题
- 没有报错信息
- 没说已经做了什么
- 别人没法直接帮你
好的问法
TEXT
【问题】用户列表接口返回500
【报错信息】java.lang.NullPointerException at UserServiceImpl.java:45
【已排查】
1. 确认userMapper不为null,可以正常调用
2. 断点发现user实体类的deptId为null
3. 数据库里dept_id字段确实有值
【猜测】可能是MyBatis字段映射问题
【问题】deptId在entity里写的deptId,数据库是dept_id,
已经配了map-underscore-to-camel-case,但没生效
【配置】application.yml里mybatis配置截图如下
好在哪里:
- 一眼看出是什么问题
- 有报错信息和位置
- 说明了已排查的内容
- 有具体的问题和猜测
- 配好了截图
四、问问题的模板
模板1:技术问题
TEXT
我在做[功能名称]时遇到一个问题:
【目标】
实现用户列表分页查询
【现象】
访问 GET /api/user/list 返回500
【报错信息】
[粘贴完整错误堆栈]
【相关代码】
[贴出Controller和Service的关键代码]
【已排查】
1. 数据库有数据
2. Mapper可以正常查询
3. 报错在Service层第XX行
【问题】
XXX为null是什么原因?
模板2:业务问题
TEXT
关于[功能名称]的业务逻辑,有个地方想确认:
【背景】
我在做用户注册功能
【疑问】
注册时需要校验手机号是否已注册,
如果手机号已存在,是返回错误提示还是覆盖更新?
【我的理解】
看代码逻辑是返回错误提示,
但产品文档里写的是"更新已有用户信息"
【问题】
应该以哪个为准?
模板3:环境问题
TEXT
项目本地启动遇到环境问题:
【目标】
在本地启动admin模块
【报错信息】
[截图或复制完整报错]
【环境信息】
- JDK版本:1.8.0_371
- Maven版本:3.9.6
- MySQL版本:8.0.36
- Redis版本:5.0.14
【已排查】
1. MySQL和Redis服务都在运行
2. 配置文件已改成local环境
3. 依赖没有爆红
【问题】
启动到Nacos连接时报错,
本地是否需要装Nacos?还是可以跳过?
五、什么时候问
15分钟原则
遇到问题先自己查15分钟。15分钟内解决了就自己搞定,解决不了就问。
不要:
- 遇到问题第一时间就问(显得不动脑子)
- 死磕一整天都不问(浪费时间)
具体时间建议
| 问题类型 | 建议时间 |
|---|---|
| 环境搭建问题 | 搞30分钟不行就问 |
| 代码报错 | 搞1小时不行就问 |
| 业务逻辑 | 不确定就问,别猜 |
| 公司规范 | 直接问 |
找谁问
| 问题类型 | 找谁 |
|---|---|
| 环境搭建 | 导师或同组同事 |
| 业务逻辑 | 产品经理或导师 |
| 技术实现 | 同组资深同事 |
| 公司规范 | 导师 |
| 线上问题 | 直接上报,别自己搞 |
六、问问题的渠道
1. 当面问
最适合复杂问题,可以面对面交流、画图、看代码。
适合: 需要讨论的问题、需要看代码的问题
2. 即时通讯(企业微信/飞书/钉钉)
最常用,但要注意方式。
好的做法:
TEXT
张哥,我在做用户列表分页,遇到个问题。
访问接口返回500,报NullPointerException。
我已经排查了数据库有数据、Mapper能查到,
报错在UserServiceImpl.java:45行。
你方便的时候帮我看下?截图如下:
不好的做法:
TEXT
张哥在吗?
张哥有空吗?
张哥帮我看个问题。
(等了10分钟没回)
张哥??
→ 一次性把问题描述清楚,不要挤牙膏式提问。
3. 截图 + 文字
截图要截全,别只截一小部分:
- 报错信息截完整堆栈
- 代码截图带上行号
- 配置截图带上文件名
4. 共享屏幕
复杂问题,共享屏幕让同事看你的操作过程,比描述高效100倍。
七、新人问问题常见错误
错误1:先问"在吗"
TEXT
❌ "在吗?"
(等回复)
"有个问题想问"
✅ "张哥,我遇到个问题:用户列表接口返回500,
报错信息是NullPointerException at xxx。
我排查了数据库和Mapper都没问题,
你方便的时候帮我看下。"
一次把问题说清楚,别人有空了直接回。
错误2:不给上下文
TEXT
❌ "我的项目报错了"
"什么报错?"
"NullPointerException"
"在哪报的?"
"UserServiceImpl"
"什么操作触发的?"
"访问用户列表"
✅ "访问用户列表接口返回500,
报NullPointerException at UserServiceImpl.java:45,
我排查发现xxx为null,
你帮我看下是什么原因。"
错误3:不搜就问
TEXT
❌ "Maven依赖爆红怎么解决?"
(百度第一条就是答案)
✅ "Maven依赖爆红,我试了刷新和删除.lastUpdated文件,
还是解决不了。我的settings.xml配置如下,
镜像也配了,你看看是不是哪里配错了。"
错误4:重复问
TEXT
❌ 今天问:"Maven怎么换镜像?"
明天问:"Maven镜像怎么配?"
(同一个问题问三遍)
✅ 第一次问完,记下来。下次自己解决。
错误5:问完不记录
TEXT
同事帮你解决了问题,你"哦知道了",
下次遇到同样的问题又不会了。
✅ 解决后记录下来:
- 什么问题
- 怎么解决的
- 根因是什么
写在自己的笔记或workbuddy memory里
错误6:只抛问题不给方案
TEXT
❌ "这个怎么做?"
✅ "这个功能我想了两种方案:
方案A:用Redis缓存,优点是xxx,缺点是xxx
方案B:用本地缓存,优点是xxx,缺点是xxx
你觉得哪种更合适?"
带着方案问问题,说明你思考过了,别人也更愿意帮。
八、被问到问题怎么回答
同事帮你解决问题后,你的反应也很重要:
好的反应
TEXT
"原来是这里的问题,我明白了。
我把解决方案记下来,下次遇到就不用麻烦你了。
谢谢张哥!"
不好的反应
TEXT
"哦。"
(什么都没记,下次还问)
或者:
TEXT
"为什么是这样?为什么不那样写?"
(同事花时间帮你解决问题,你还要质疑)
九、建立自己的知识库
每次问完问题后记录
用任何工具都行(笔记软件、Markdown文件、workbuddy memory):
Markdown
## 2026-01-01 问题记录
### 问题1:用户列表接口返回500
- 原因:User实体类的deptId字段没加@TableField注解
- 解决:加@TableField("dept_id")
- 根因:MyBatis字段映射配置没生效,手动指定列名
- 下次:遇到字段映射问题先检查@TableField注解
### 问题2:Redis连接失败
- 原因:Redis设了密码但配置文件没配password
- 解决:application.yml里加spring.redis.password
- 根因:配置遗漏
- 下次:先redis-cli ping测试Redis连通性
积累下来,这就是你的经验。
十、和导师/同事的沟通节奏
入职第一周
- 每天5-10分钟同步进度:"今天搞完了环境搭建,明天开始看代码"
- 遇到问题直接问,不要不好意思
入职第一个月
- 每周1-2次主动同步:"这周做了XX功能,遇到了XX问题,已解决"
- 问题尽量自己先查,实在不行再问
入职三个月后
- 基本能独立开发了
- 遇到的问题应该越来越高级,不再是环境搭建级别的
小结
| 要点 | 说明 |
|---|---|
| 先搜索再问 | 15分钟原则 |
| 一次性描述清楚 | 问题+报错+已排查+截图 |
| 带着方案问 | 说明你思考过了 |
| 问完记录下来 | 不重复问 |
| 控制频率 | 不要太频繁也不要死磕 |
好的提问方式 = 高效解决问题 + 展示你的专业态度。