JSP 项目在 Ubuntu 上出问题时，真正耗时间的往往不是写代码，而是判断问题卡在环境、后端执行、前端渲染，还是远程部署链路。下面按最常见的几种调试场景拆开说明，从本地 IDE 断点到日志、浏览器开发者工具，再到远程调试，尽量让你在遇到报错时能更快选对方法，而不是把所有手段都试一遍。

先把 Ubuntu 上的调试基础环境配好

开始调试前，建议先确认 JDK、Tomcat 和 IDE 这三部分都处于可用状态。很多看起来像“代码问题”的报错，最后往往是环境没有装完整，或者版本、路径没有对上。

JDK：优先确认版本和命令可用

JSP 项目通常建议使用 OpenJDK 11 或更高版本，兼容性相对更稳。Ubuntu 下可以直接安装：

sudo apt update && sudo apt install openjdk-11-jdk

安装完成后，先检查运行时和编译器是否都可用：

java -version
javac -version

如果这两条命令输出正常，说明 JDK 本身和基础环境变量通常已经没有问题。

Tomcat：先保证服务能启动

在 Ubuntu 上，Tomcat 9 是比较常见的选择。安装命令如下：

sudo apt install tomcat9 tomcat9-admin

安装后可以先启动服务：

sudo systemctl start tomcat9

如果希望开机自动启动，再执行：

sudo systemctl enable tomcat9

这一步的重点不是“装完就算完成”，而是确认 Tomcat 能正常起来，否则后面的断点、日志和远程调试都无从谈起。

IDE：Eclipse 和 IDEA 都能用

IDE 方面，Eclipse（Java EE 版）和 IntelliJ IDEA（社区版或终极版）都支持 JSP 项目调试。如果更看重开箱即用的体验，很多人会更倾向于使用 IDEA。

用 IDE 做图形化调试，适合大多数日常问题

如果你需要看断点、变量、调用过程，IDE 的图形化调试通常是最直接的一条路。对新手来说，这也是最容易建立调试思路的方式。下面以 IntelliJ IDEA 为例说明。

第一步：导入项目并挂上 Tomcat

在 IDEA 中选择 File → New → Project from Existing Sources，导入你的 JSP 项目。Maven 或 Gradle 项目都可以按现有结构导入。

接着进入 Run → Edit Configurations，新增 Tomcat Server → Local 配置，填写 Tomcat 安装目录，例如 /opt/tomcat。然后在 Deployment 标签页里添加项目的 war 包或 exploded 目录。

第二步：设置断点并启动 Debug

你可以在 JSP 文件，例如 index.jsp，或者对应的 Servlet 代码行号旁边点击设置断点。出现红点后，点击工具栏中的 Debug 按钮启动 Tomcat 调试模式。

然后在浏览器中访问：

http://localhost:8080/your_project_name

当请求执行到断点位置时，IDE 会暂停程序。此时就可以进入真正的排查阶段。

第三步：重点看变量和执行路径

断点停住后，常用操作主要有这几类：

• Step Over：逐行执行，但不进入方法内部。
• Step Into：进入当前调用的方法。
• Step Out：从当前方法退出，回到上层调用。
• Variables：查看当前变量值和对象状态。
• Evaluate Expression：临时计算表达式，适合验证条件分支或对象字段。

如果你已经能稳定复现问题，IDE 调试通常最适合查这类场景：参数传递错误、条件判断走偏、对象为空、Servlet 与 JSP 之间的数据没有按预期流转。

不用断点时，命令行、日志和浏览器工具怎么配合

并不是所有问题都适合靠 IDE 断点解决。比如服务器环境受限、问题偶发、页面表现异常，或者你只想快速验证某段逻辑，这时命令行、日志和浏览器工具往往更高效。

命令行调试：JDB 更适合基础排查

JDK 自带的 jdb 可以做命令行调试，但它更适合调试已编译的 Java 类。对 JSP 来说，通常要先落到对应的 Servlet/Java 类层面来处理。

基础流程如下：

• 先用 javac 编译相关 Java 文件，例如 MyServlet.java，生成 .class。
• 启动调试器：

jdb MyServlet

• 在方法上设置断点：

stop in MyServlet.doGet

• 运行程序：

run

常用命令包括：

step
next
print variableName
cont

它们分别对应单步执行、跳过方法调用、查看变量值和继续运行。对纯后端逻辑来说够用，但如果问题涉及 JSP 页面与容器配合，IDE 仍然更省时间。

日志调试：适合持续观察和复杂问题复盘

日志调试的优势在于不打断程序执行，适合排查线上复现不稳定的问题，也适合长期保留线索。常见做法是给项目接入 Log4j 2 或 SLF4J。下面以 Log4j 2 为例。

先在 Maven 的 pom.xml 或 Gradle 的 build.gradle 中加入依赖：

org.apache.logging.log4jlog4j-core2.20.0org.apache.logging.log4jlog4j-api2.20.0

然后在 src/main/resources 下创建 log4j2.xml，定义日志级别和输出目标：

代码里可以这样记录请求信息：

import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;public class MyServlet extends HttpServlet {private static final Logger logger = LogManager.getLogger(MyServlet.class);protected void doGet(HttpServletRequest request, HttpServletResponse response) {logger.debug("Received GET request from IP: " + request.getRemoteAddr());// 其他代码...}}

运行后可以直接看控制台输出，也可以把日志写入文件，例如 logs/app.log。如果问题跟请求进入顺序、参数值变化、某个分支是否被执行有关，日志通常比反复打断点更稳。

浏览器开发者工具：前后端交界问题优先看这里

JSP 页面的问题并不总是后端逻辑导致的。页面渲染异常、JavaScript 报错、AJAX 请求失败，这些都更适合在浏览器开发者工具里查。

在 Chrome 中按 F12 或 Ctrl+Shift+I 打开开发者工具后，先重点看 Console 标签页。这里能直接看到 JS 错误、接口响应异常等信息。

如果你在调样式或前端交互逻辑，还可以使用 Sources 里的 Overrides 功能。勾选 Enable Local Overrides 后，选择本地目录，例如 ~/overrides，就可以对页面资源进行本地覆盖调试。这样修改后通常能更快观察效果，减少频繁重启或重新部署带来的干扰。

项目跑在远程 Ubuntu 服务器上，如何做远程调试

当 JSP 项目不在本机，而是部署在远程 Ubuntu 服务器上时，远程调试会比“看日志猜问题”更直接。只要 Tomcat 开启调试端口，IDE 就能像调本地进程一样连接过去。

先让 Tomcat 打开调试端口

编辑 $CATALINA_HOME/bin 目录下的 catalina.sh，在文件开头加入：

export CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"

这表示 Tomcat 会通过 JDWP 在 5005 端口监听调试连接。

然后启动 Tomcat：

$CATALINA_HOME/bin/startup.sh

再在 IDEA 里配置 Remote JVM Debug

打开 Run → Edit Configurations，新增 Remote JVM Debug 配置。将 Host 设为服务器 IP，例如 192.168.1.100，Port 设为 5005。

点击 Debug 后，IDE 会尝试连接远程 Tomcat。接着在浏览器中访问远程页面：

http://192.168.1.100:8080/your_project

请求命中断点后，就可以直接查看变量、调用栈和执行路径。对“本地正常、服务器异常”这类问题，远程调试往往是最有效的手段之一。

最后再补两种很实用的排查手段

有些问题并不值得上完整调试流程，尤其是在你只想快速确认某个变量、或者先定位异常发生位置的时候，下面两种方式依然很有价值。

System.out.println() 仍然适合快速验证

虽然它看起来很传统，但在简单场景下确实高效。你可以直接在可疑代码前后打印变量：

System.out.println("变量值：" + variable)

输出通常会进入 Tomcat 控制台，或者写到 $CATALINA_HOME/logs/catalina.out。当你只想确认“代码有没有执行到这里”或者“这个值是不是空”，它往往比开一整套调试配置更快。

Tomcat 日志是运行时错误的第一现场

如果应用已经抛错，优先看 Tomcat 日志通常最直接。常见的两个位置是：

• catalina.out：Tomcat 主日志
• localhost..log：应用相关日志

像 NullPointerException、ServletException 这类运行时异常，通常都能在这里找到堆栈信息。先从日志里确认异常类型、报错位置和调用链，再决定是否需要进一步用断点或远程调试深入跟进，会比盲目逐段排查更有效率。

怎么选调试方式，关键看你现在卡在哪一层

如果你是在本地开发阶段遇到逻辑错误，优先用 IDE 断点；如果问题需要长期观察，或者不方便中断运行，优先补日志；如果页面表现不对，先开浏览器开发者工具；如果异常只出现在服务器环境，再上远程调试。

JSP 在 Ubuntu 上并不难调，难的是一开始就选错排查入口。把环境先确认好，再按“后端执行、前端表现、部署环境”这三层去判断，通常能比单纯盯着控制台更快把问题收敛下来。