拿到“JSP智能股票选取系统3s1h2程序源码数据库调试部署开发环境”这套交付物的时候我第一反应不是赶紧双击启动而是先把目录结构完整看了一遍。做这类事情的次数多了你会形成一种条件反射老牌Java Web项目真正杀人的从来不是算法多么复杂而是开发环境、数据库脚本、部署路径这三样东西对不对齐。所谓3s1h2其实就是一个内部版本标识不用过度解读你只需要知道这套东西包含源码、数据库、调试部署文档和开发环境配置接下来要做的事情就是把这个带标识的项目完整还原成一台能点开页面、能跑通选股逻辑的Web应用。这篇文章写给谁写给拿到底层代码但缺操作路径的人也写给想用JSP技术二次实现选股系统的学生和开发者。我会从项目目录怎么拆、数据库怎么初始化、Tomcat怎么部署、评分逻辑怎么读、常见的坑怎么排五个方面来拆解保证每一步都能照着做不是那种看完全文还不知道从哪里下手的空话。1. 先拆清楚这套交付包里到底有哪些东西1.1 源码目录和数据库脚本的分工老式JSP项目和新式Spring Boot项目最大的区别就是没有统一的目录标准。你打开这个名为3s1h2的交付包大概率会看到类似下面的目录这几乎是惯例级的存在stockpicker-3s1h2/ ├── src/ │ ├── com/example/dao │ ├── com/example/model │ ├── com/example/servlet │ └── com/example/util ├── WebContent/ │ ├── WEB-INF/ │ │ ├── web.xml │ │ └── lib/ │ ├── css/ │ ├── js/ │ ├── index.jsp │ ├── query.jsp │ └── result.jsp └── sql/ └── stock_picker.sql第一眼不要被数量众多的JSP文件吓到它们的核心任务是展示页面真正处理数据的是src里的Servlet和DAO。我的建议是先看sql目录因为选股系统本质上是数据驱动系统如果数据库没起来页面做得再好也是空壳。再看WebContent/WEB-INF/web.xml这个文件记录了请求URL和Servlet类的映射关系等于说是系统的路由表很多页面打不开的问题最后都能在它身上找到原因。1.2 为什么2025年还会有JSP类型的选股系统很多人问过我现在前后端分离到处都是为什么还要折腾JSP这种相对传统的技术。这里面的道理其实很简单选股系统是一个典型的低并发、重查询、重后台计算的场景。用户量不会像电商那样爆发式增长核心价值集中在指标计算、排序筛选、结果展示服务端渲染反而比前后端分离更容易维护。数据库连接用JDBC直连配合Tomcat部署不需要额外维护Node服务或者复杂网关对老机器和旧环境非常友好。还有一个很实际的原因很多高校的Java课程和实训项目还在使用JSPServletJDBC这套组合。这类题目的考核点不是前端交互有多炫酷而是能不能把一条SQL写对、把数据从数据库拿到页面上。所以这套源码的价值不止在“能跑”更在于它的结构足够经典适合当作一个完整的Web应用蓝本来读。2. 数据库才是真正的地基初始化顺序决定成败2.1 表结构设计和评分字段来源我见过不少人在这一步翻车拿到脚本就无脑执行结果报了二十多个错误然后跑来问我是不是源码有问题。其实数据库初始化这件事关键不是命令有多高级而是表的设计逻辑能不能支撑起选股业务。整套系统通常包含这几张核心表stock_info股票基础信息包括代码、名称、行业分类、上市日期daily_kline历史行情表记录每个交易日的开盘价、收盘价、最高价、最低价、成交量、换手率strategy_params策略参数表保存用户选择的评分阈值比如均线周期、相对强弱指标上下限stock_score结果表把计算出来的综合评分和排名结果落库方便页面快速展示。典型的建表SQL长这样CREATE DATABASE stock_picker DEFAULT CHARACTER SET utf8mb4; USE stock_picker; CREATE TABLE stock_info ( stock_code VARCHAR(12) PRIMARY KEY, stock_name VARCHAR(64), industry VARCHAR(64), listed_date DATE ); CREATE TABLE daily_kline ( id INT AUTO_INCREMENT PRIMARY KEY, stock_code VARCHAR(12), trade_date DATE, open_price DECIMAL(10,2), close_price DECIMAL(10,2), high_price DECIMAL(10,2), low_price DECIMAL(10,2), volume BIGINT, turnover_rate DECIMAL(10,4), KEY idx_code_date (stock_code, trade_date) );注意看daily_kline表的字段类型价格都用DECIMAL而不是FLOAT因为浮点数计算会出现误差金融数据对精度很敏感哪怕只有一分钱的误差在排名时都可能造成完全不同的结果。idx_code_date联合索引也是故意加的因为选股逻辑里最常见的操作就是“查某只股票最近N天的行情”没有这个索引数据量过万之后查询速度会肉眼可见地变慢。2.2 数据导入顺序和常见导入报错导入数据不要一股脑地拖进客户端里执行。先把数据库建好再导入表结构最后导入数据这个顺序不能乱。命令行方式最稳因为能看到每一步的输出mysql -u root -p sql/stock_picker.sql如果脚本文件里本身没有建库语句那就先手动建库再指定库名导入mysql -u root -p -e CREATE DATABASE IF NOT EXISTS stock_picker DEFAULT CHARACTER SET utf8mb4; mysql -u root -p stock_picker sql/stock_picker.sql常见报错就那么几种。一种是“Unknown database”说明库没建一种是“Table already exists”说明你重复执行了脚本还有一种是数据导入时提示字段长度超出范围比如股票代码字段设计成VARCHAR(6)但你导入的数据里包含了带后缀的代码就会卡住。我自己的做法是导入之前先打开SQL脚本快速看一下是哪些表的INSERT语句优先确认有没有超过字段长度的风险不是盲目双击执行。另外强烈建议在导入命令里不加--force这类忽略错误的参数因为错误信息是最好的排错线索强制跳过只会让你面对一张“看起来建好了但逻辑全错”的数据库。3. 从源码到可以点开页面完整的调试部署流程3.1 开发环境统一版本这套系统能不能顺利部署很大程度取决于环境版本匹配。我建议先按下面这张表对齐环境再开始后面的操作版本错位造成的疑难杂症比代码本身难处理得多组件推荐版本说明JDK8 或 11老项目不建议用太高版本部分反射和类加载逻辑在新JDK下容易报警告Tomcat8.5 或 9.0对应Servlet 3.1/4.0标准足够支撑JSPMySQL5.7 或 8.0注意驱动版本JDBC连接串写法不一样IDEEclipse 或 IntelliJ IDEAEclipse对老Web项目兼容更直观IDEA需要手动配Facets数据库驱动mysql-connector-java 5.1.x 或 8.0.x必须和MySQL大版本匹配别在这步偷懒。不少人用Java 17跑老项目Tomcat 7配MySQL 8连Class.forName都报了异常然后怀疑源码坏了。绝大多数情况下源码没坏坏的是组合方式。3.2 数据库连接配置找配置文件是这一步的核心工作。老式项目通常会有一个jdbc.properties或者db.properties文本内容类似jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/stock_picker?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password123456注意如果MySQL是8.0驱动类名要写com.mysql.cj.jdbc.Driver不是老的com.mysql.jdbc.Driver。URL里的serverTimezone也经常被忽略不写的话运行时会报时区异常这个坑很多刚接触的人会踩。密码不要用特殊字符过多如果密码里有#或记得在properties里转义或用单引号处理。3.3 部署到Tomcat最容易忽略的lib目录IDE里直接运行和部署到真实Tomcat有一个关键区别IDE会自动把JAR包加到编译classpath但Tomcat只认WEB-INF/lib目录下的JAR包。所以如果mysql驱动JAR只出现在Maven本地仓库或者Eclipse的 Classpath里启动后刚访问页面就报ClassNotFoundException。解决方式非常简单找到mysql-connector-java的JAR文件复制到WebContent/WEB-INF/lib/目录然后重新发布。同理如果在代码里用到了JSON库也要把对应的JAR放进去否则IDEA里一切正常换成独立Tomcat就崩。这一步做完之后把项目导出为WAR包放到Tomcat的webapps目录下或者直接在IDE的Servers视图中启动。在浏览器访问http://localhost:8080/stockpicker/index.jsp能打开首页说明部署骨架已经通了。3.4 功能验证清单部署成功不等于系统可用我习惯按照下面的清单逐项验证首页能否正常打开并显示查询表单选择查询日期和策略参数后能否正常提交结果页能否展示评分排名且收录的数据条数和数据库中一致点击查看某只股票详情时能否显示该股票的历史行情表格Tomcat控制台没有红色异常的堆栈输出。如果第2步就报错先回控制台看异常类型绝大多数是数据库连接或SQL语法的错误这两类问题的排查方向是截然不同的。4. 拆解“智能选取”的评分逻辑这是系统和普通筛选器的分水岭4.1 从单条件查询到加权评分所谓“智能选取”不能只是简单地把WHERE close_price open_price这类条件拼在SQL里那是查询不是选取。真正的选股系统要考虑多个维度再把各维度归一化成一个综合分。这里拿一个常见的设计来讲系统维护一个评分功能对候选池中的每只股票计算趋势分、动能分、稳定分三个子分数。趋势分看均线排列动能分看近期涨跌力度稳定分看波动率。三个分数按0.4、0.3、0.3的比例加权得到一个百分制的综合评分最后按评分倒序圈定结果。这个逻辑不算复杂但它已经具备了一个智能选取系统的雏形参数可行、逻辑可解释、结果可调平。核心代码会集中在某个Service类里简化之后长这样public class ScoreCalculator { private static final double TREND_WEIGHT 0.4; private static final double MOMENTUM_WEIGHT 0.3; private static final double STABILITY_WEIGHT 0.3; public double calculate(StockInfo info, KlineData data) { double trendScore scoreTrend(info); double momentumScore scoreMomentum(data); double stabilityScore scoreStability(data); return TREND_WEIGHT * trendScore MOMENTUM_WEIGHT * momentumScore STABILITY_WEIGHT * stabilityScore; } }这一段基本说明了整个系统的核心不是JSP标签怎么写而是三个子评分的实现方法是否合理。读源码的时候优先定位这个类把三个算分子方法看完你对整套系统的理解就能超过一半能把它跑起来的人。4.2 为什么核心计算要拆成SQL过滤加Java算分真正写项目的时候你会发现大量计算放在SQL里会变得难以调试。比如把均线、波动率全部写进一条几百行的SQL一旦结果不对你是先查数据还是先查语法我建议的基础策略是用SQL做粗粒度过滤把范围缩到千量级以内再用Java逐条算综合分。这样做有两个实际好处。第一避免全表扫描加多层子查询造成的性能负担数据库只需要返回原始行情剩下的加权计算交给应用层第二Java代码方便加日志。在每个算分子方法里输出中间结果比如趋势分是80、动能分是60、稳定分是70你能一眼看出到底是数据源问题还是权重设计问题。调试时记得一个原则先用固定股票和固定日期跑一遍手算一次期望分数然后对比系统输出差值超过0.01就需要查是不是类型转换或四舍五入的精度问题。4.3 评分逻辑里容易被忽略的边界情况我还想提醒一个容易栽的地方评分之前一定要过滤数据不足的股票。比如计算20日均线但某只股票上市才10天数据不够强行计算会出现空值或错误结果。老实现里常见的写法是直接跳过这种股票而不是给0分因为0分会让它排到最底部但这不代表它真的差而是样本不足。数据库脚本里可以预处理掉这类数据Java端也要加一个if (klineList.size() minimumDays) continue;的防御性判断。5. 调试部署阶段绕不开的5个坑5.1 404错误和web.xml映射问题页面打不开先不要重新启动服务而是看URL里的路径和web.xml中的url-pattern是否一致。JSP项目里经常出现这样的情况你访问/stockpicker/queryStock但web.xml里只配了/stock/query那必然404。排查思路是打开项目里的web.xml找到所有servlet-mapping把请求路径和映射逐行对比。这个问题和代码逻辑半毛钱关系都没有纯粹是路径对齐问题。5.2 JDBC驱动找不到出现java.lang.ClassNotFoundException: com.mysql.jdbc.Driver九成是JAR包没进WEB-INF/lib。另一成的可能是在jdbc.properties里写成了全角标点或多余空格导致驱动类名加载失败。解决办法是把JAR包放到位重新清理Tomcat的临时缓存再重启。注意有些IDE不会自动同步lib目录新增文件需要手动执行一次Clean操作。5.3 中文乱码乱码问题通常不是显示层的问题而是贯穿了请求、转码、数据库存储三条链路。从Tomcat的server.xml里设置URIEncodingUTF-8到JSP页面头部写pageEncodingUTF-8再到数据库连接URL里的characterEncodingutf8任何一处断掉都会乱码。判断断点位置有个方法如果查询条件里的中文乱多半是请求编码问题如果页面上展示的历史名称乱多半是数据库读取出错如果插入数据库之前就乱则优先检查JSP源码文件保存的编码格式。这三条链路你顺一遍绝大多数乱码都能解决。5.4 MySQL 8.0的驱动类名和SSL警告MySQL 8.0时代驱动类名变成了com.mysql.cj.jdbc.Driver连接URL里建议加上useSSLfalse和serverTimezone前者是为了避免没有配置证书时打印一堆SSL警告后者是为了解决时区偏移。很多旧配置直接沿用了com.mysql.jdbc.Driver不是不能运行而是会触发警告并有可能在特定场景下行为异常。我的建议是在升级数据库时顺便把驱动配置更新一遍不要省这一步。5.5 端口占用和Tomcat启动失败Tomcat默认端口是8080如果被其他进程占用启动时日志会写Port already in use。解决方式是在配置文件的Connector节点里改端口或者找出占用进程结束它。Windows下常用netstat -ano | findstr 8080 taskkill /PID 进程号 /F这里重点提示改Tomcat端口不要只改一处server.xml里可能有多个Connector包括HTTP和AJP生产环境还要考虑防火墙放行对应端口。5.6 一次完整排查链路示例有一次我给某台机器部署这个系统启动正常首页打开也正常但是一点查询按钮就报500错。我没有直接改代码而是先看了Tomcat的logs/localhost.yyyy-MM-dd.log发现异常栈里写着SQLException: Unknown column s.turnover_rate。这明显是SQL里引用了一个表中不存在的字段。接着我打开数据库客户端执行DESC daily_kline;发现字段名是turnoverrate不是turnover_rate。问题的根因一下就清楚了源码是按下划线命名写的但初始SQL脚本里建表时用了不带下划线的字段名。两点对齐之后我把SQL里的列名改成和数据库一致重新发布问题就消失了。这类问题看起来吓人但只要按照“看日志、看表结构、对照字段名”三步走十几分钟就能定位不要一上来就怀疑项目不能跑。6. 从跑通到改造成自己的系统三个可落地的扩展方向6.1 策略参数模块化很多人的第一个需求就是“想换策略”。直接在源码里改数字改完就乱了下次想切回原策略又得翻代码。更好的做法是把参数配置做到数据库表里比如strategy_params表保存均线周期、评分权重、筛选阈值页面提供一个管理表单用户改了参数之后查询逻辑每次从数据库读取。这样做的好处是策略调整不用重新编译省下的时间非常可观。改造时只需在Service层增加一个读取策略的逻辑代码上下文保持不变页面和DAO层的改动非常少。我实际改造时大概花了半个小时之后调参体验提升了一个档次。6.2 增加新指标和数据源如果觉得三因子评分不够用可以往daily_kline表增加字段比如增加一个amplitude字段记录振幅再把新指标接入ScoreCalculator。增加字段不是难题真正要处理的是历史数据怎么补齐。这里建议最好在数据库脚本里预留备用字段或者做一套独立的CSV导入工具避免后续全部手工改数据。如果你是自建学习环境不建议用真实生产环境的口径去采集大量历史行情重点在于把流程跑通用模拟数据或者少量公开测试数据就足够验证项目的业务闭环。对系统本身而言它的价值在于展示如何从数据库到页面再到参数配置形成完整的选取链路。6.3 经验与注意事项写这类JSP系统的核心经验我总结成一句话先稳定数据库再理解部署最后改逻辑。数据库没跑通之前所有页面上的报错都会指向同一个假象“源码有问题”。实际上源码通常没有问题问题大多出在环境匹配和数据格式上。调试的时候要舍得花时间看异常堆栈不要只看最后一行。顶部的Caused by才是罪魁祸首你从下往上看才能找到真正的原因。这个习惯适用于任何Java Web项目不止选股系统。最后再分享一个我个人的操作习惯每次拿到这类“源码数据库调试部署”交付包我都会先把数据库脚本另存一份然后在副本里执行和修改。这样做既能保留原始参考样例又能放心大胆地加自己的策略参数。等系统稳定跑起来之后再决定要不要把这些改动合并回主项目。这种留一手的习惯在调试阶段能帮你避免很多重复劳动也让你在把项目改坏的时候永远有一条回头路。 
长河君 · 2026/10/16 6:58:11 · 阅读 1.2k JSP智能股票选取系统部署实战：源码、数据库与调试全解析
拿到“JSP智能股票选取系统3s1h2程序源码数据库调试部署开发环境”这套交付物的时候我第一反应不是赶紧双击启动而是先把目录结构完整看了一遍。做这类事情的次数多了你会形成一种条件反射老牌Java Web项目真正杀人的从来不是算法多么复杂而是开发环境、数据库脚本、部署路径这三样东西对不对齐。所谓3s1h2其实就是一个内部版本标识不用过度解读你只需要知道这套东西包含源码、数据库、调试部署文档和开发环境配置接下来要做的事情就是把这个带标识的项目完整还原成一台能点开页面、能跑通选股逻辑的Web应用。这篇文章写给谁写给拿到底层代码但缺操作路径的人也写给想用JSP技术二次实现选股系统的学生和开发者。我会从项目目录怎么拆、数据库怎么初始化、Tomcat怎么部署、评分逻辑怎么读、常见的坑怎么排五个方面来拆解保证每一步都能照着做不是那种看完全文还不知道从哪里下手的空话。1. 先拆清楚这套交付包里到底有哪些东西1.1 源码目录和数据库脚本的分工老式JSP项目和新式Spring Boot项目最大的区别就是没有统一的目录标准。你打开这个名为3s1h2的交付包大概率会看到类似下面的目录这几乎是惯例级的存在stockpicker-3s1h2/ ├── src/ │ ├── com/example/dao │ ├── com/example/model │ ├── com/example/servlet │ └── com/example/util ├── WebContent/ │ ├── WEB-INF/ │ │ ├── web.xml │ │ └── lib/ │ ├── css/ │ ├── js/ │ ├── index.jsp │ ├── query.jsp │ └── result.jsp └── sql/ └── stock_picker.sql第一眼不要被数量众多的JSP文件吓到它们的核心任务是展示页面真正处理数据的是src里的Servlet和DAO。我的建议是先看sql目录因为选股系统本质上是数据驱动系统如果数据库没起来页面做得再好也是空壳。再看WebContent/WEB-INF/web.xml这个文件记录了请求URL和Servlet类的映射关系等于说是系统的路由表很多页面打不开的问题最后都能在它身上找到原因。1.2 为什么2025年还会有JSP类型的选股系统很多人问过我现在前后端分离到处都是为什么还要折腾JSP这种相对传统的技术。这里面的道理其实很简单选股系统是一个典型的低并发、重查询、重后台计算的场景。用户量不会像电商那样爆发式增长核心价值集中在指标计算、排序筛选、结果展示服务端渲染反而比前后端分离更容易维护。数据库连接用JDBC直连配合Tomcat部署不需要额外维护Node服务或者复杂网关对老机器和旧环境非常友好。还有一个很实际的原因很多高校的Java课程和实训项目还在使用JSPServletJDBC这套组合。这类题目的考核点不是前端交互有多炫酷而是能不能把一条SQL写对、把数据从数据库拿到页面上。所以这套源码的价值不止在“能跑”更在于它的结构足够经典适合当作一个完整的Web应用蓝本来读。2. 数据库才是真正的地基初始化顺序决定成败2.1 表结构设计和评分字段来源我见过不少人在这一步翻车拿到脚本就无脑执行结果报了二十多个错误然后跑来问我是不是源码有问题。其实数据库初始化这件事关键不是命令有多高级而是表的设计逻辑能不能支撑起选股业务。整套系统通常包含这几张核心表stock_info股票基础信息包括代码、名称、行业分类、上市日期daily_kline历史行情表记录每个交易日的开盘价、收盘价、最高价、最低价、成交量、换手率strategy_params策略参数表保存用户选择的评分阈值比如均线周期、相对强弱指标上下限stock_score结果表把计算出来的综合评分和排名结果落库方便页面快速展示。典型的建表SQL长这样CREATE DATABASE stock_picker DEFAULT CHARACTER SET utf8mb4; USE stock_picker; CREATE TABLE stock_info ( stock_code VARCHAR(12) PRIMARY KEY, stock_name VARCHAR(64), industry VARCHAR(64), listed_date DATE ); CREATE TABLE daily_kline ( id INT AUTO_INCREMENT PRIMARY KEY, stock_code VARCHAR(12), trade_date DATE, open_price DECIMAL(10,2), close_price DECIMAL(10,2), high_price DECIMAL(10,2), low_price DECIMAL(10,2), volume BIGINT, turnover_rate DECIMAL(10,4), KEY idx_code_date (stock_code, trade_date) );注意看daily_kline表的字段类型价格都用DECIMAL而不是FLOAT因为浮点数计算会出现误差金融数据对精度很敏感哪怕只有一分钱的误差在排名时都可能造成完全不同的结果。idx_code_date联合索引也是故意加的因为选股逻辑里最常见的操作就是“查某只股票最近N天的行情”没有这个索引数据量过万之后查询速度会肉眼可见地变慢。2.2 数据导入顺序和常见导入报错导入数据不要一股脑地拖进客户端里执行。先把数据库建好再导入表结构最后导入数据这个顺序不能乱。命令行方式最稳因为能看到每一步的输出mysql -u root -p sql/stock_picker.sql如果脚本文件里本身没有建库语句那就先手动建库再指定库名导入mysql -u root -p -e CREATE DATABASE IF NOT EXISTS stock_picker DEFAULT CHARACTER SET utf8mb4; mysql -u root -p stock_picker sql/stock_picker.sql常见报错就那么几种。一种是“Unknown database”说明库没建一种是“Table already exists”说明你重复执行了脚本还有一种是数据导入时提示字段长度超出范围比如股票代码字段设计成VARCHAR(6)但你导入的数据里包含了带后缀的代码就会卡住。我自己的做法是导入之前先打开SQL脚本快速看一下是哪些表的INSERT语句优先确认有没有超过字段长度的风险不是盲目双击执行。另外强烈建议在导入命令里不加--force这类忽略错误的参数因为错误信息是最好的排错线索强制跳过只会让你面对一张“看起来建好了但逻辑全错”的数据库。3. 从源码到可以点开页面完整的调试部署流程3.1 开发环境统一版本这套系统能不能顺利部署很大程度取决于环境版本匹配。我建议先按下面这张表对齐环境再开始后面的操作版本错位造成的疑难杂症比代码本身难处理得多组件推荐版本说明JDK8 或 11老项目不建议用太高版本部分反射和类加载逻辑在新JDK下容易报警告Tomcat8.5 或 9.0对应Servlet 3.1/4.0标准足够支撑JSPMySQL5.7 或 8.0注意驱动版本JDBC连接串写法不一样IDEEclipse 或 IntelliJ IDEAEclipse对老Web项目兼容更直观IDEA需要手动配Facets数据库驱动mysql-connector-java 5.1.x 或 8.0.x必须和MySQL大版本匹配别在这步偷懒。不少人用Java 17跑老项目Tomcat 7配MySQL 8连Class.forName都报了异常然后怀疑源码坏了。绝大多数情况下源码没坏坏的是组合方式。3.2 数据库连接配置找配置文件是这一步的核心工作。老式项目通常会有一个jdbc.properties或者db.properties文本内容类似jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/stock_picker?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password123456注意如果MySQL是8.0驱动类名要写com.mysql.cj.jdbc.Driver不是老的com.mysql.jdbc.Driver。URL里的serverTimezone也经常被忽略不写的话运行时会报时区异常这个坑很多刚接触的人会踩。密码不要用特殊字符过多如果密码里有#或记得在properties里转义或用单引号处理。3.3 部署到Tomcat最容易忽略的lib目录IDE里直接运行和部署到真实Tomcat有一个关键区别IDE会自动把JAR包加到编译classpath但Tomcat只认WEB-INF/lib目录下的JAR包。所以如果mysql驱动JAR只出现在Maven本地仓库或者Eclipse的 Classpath里启动后刚访问页面就报ClassNotFoundException。解决方式非常简单找到mysql-connector-java的JAR文件复制到WebContent/WEB-INF/lib/目录然后重新发布。同理如果在代码里用到了JSON库也要把对应的JAR放进去否则IDEA里一切正常换成独立Tomcat就崩。这一步做完之后把项目导出为WAR包放到Tomcat的webapps目录下或者直接在IDE的Servers视图中启动。在浏览器访问http://localhost:8080/stockpicker/index.jsp能打开首页说明部署骨架已经通了。3.4 功能验证清单部署成功不等于系统可用我习惯按照下面的清单逐项验证首页能否正常打开并显示查询表单选择查询日期和策略参数后能否正常提交结果页能否展示评分排名且收录的数据条数和数据库中一致点击查看某只股票详情时能否显示该股票的历史行情表格Tomcat控制台没有红色异常的堆栈输出。如果第2步就报错先回控制台看异常类型绝大多数是数据库连接或SQL语法的错误这两类问题的排查方向是截然不同的。4. 拆解“智能选取”的评分逻辑这是系统和普通筛选器的分水岭4.1 从单条件查询到加权评分所谓“智能选取”不能只是简单地把WHERE close_price open_price这类条件拼在SQL里那是查询不是选取。真正的选股系统要考虑多个维度再把各维度归一化成一个综合分。这里拿一个常见的设计来讲系统维护一个评分功能对候选池中的每只股票计算趋势分、动能分、稳定分三个子分数。趋势分看均线排列动能分看近期涨跌力度稳定分看波动率。三个分数按0.4、0.3、0.3的比例加权得到一个百分制的综合评分最后按评分倒序圈定结果。这个逻辑不算复杂但它已经具备了一个智能选取系统的雏形参数可行、逻辑可解释、结果可调平。核心代码会集中在某个Service类里简化之后长这样public class ScoreCalculator { private static final double TREND_WEIGHT 0.4; private static final double MOMENTUM_WEIGHT 0.3; private static final double STABILITY_WEIGHT 0.3; public double calculate(StockInfo info, KlineData data) { double trendScore scoreTrend(info); double momentumScore scoreMomentum(data); double stabilityScore scoreStability(data); return TREND_WEIGHT * trendScore MOMENTUM_WEIGHT * momentumScore STABILITY_WEIGHT * stabilityScore; } }这一段基本说明了整个系统的核心不是JSP标签怎么写而是三个子评分的实现方法是否合理。读源码的时候优先定位这个类把三个算分子方法看完你对整套系统的理解就能超过一半能把它跑起来的人。4.2 为什么核心计算要拆成SQL过滤加Java算分真正写项目的时候你会发现大量计算放在SQL里会变得难以调试。比如把均线、波动率全部写进一条几百行的SQL一旦结果不对你是先查数据还是先查语法我建议的基础策略是用SQL做粗粒度过滤把范围缩到千量级以内再用Java逐条算综合分。这样做有两个实际好处。第一避免全表扫描加多层子查询造成的性能负担数据库只需要返回原始行情剩下的加权计算交给应用层第二Java代码方便加日志。在每个算分子方法里输出中间结果比如趋势分是80、动能分是60、稳定分是70你能一眼看出到底是数据源问题还是权重设计问题。调试时记得一个原则先用固定股票和固定日期跑一遍手算一次期望分数然后对比系统输出差值超过0.01就需要查是不是类型转换或四舍五入的精度问题。4.3 评分逻辑里容易被忽略的边界情况我还想提醒一个容易栽的地方评分之前一定要过滤数据不足的股票。比如计算20日均线但某只股票上市才10天数据不够强行计算会出现空值或错误结果。老实现里常见的写法是直接跳过这种股票而不是给0分因为0分会让它排到最底部但这不代表它真的差而是样本不足。数据库脚本里可以预处理掉这类数据Java端也要加一个if (klineList.size() minimumDays) continue;的防御性判断。5. 调试部署阶段绕不开的5个坑5.1 404错误和web.xml映射问题页面打不开先不要重新启动服务而是看URL里的路径和web.xml中的url-pattern是否一致。JSP项目里经常出现这样的情况你访问/stockpicker/queryStock但web.xml里只配了/stock/query那必然404。排查思路是打开项目里的web.xml找到所有servlet-mapping把请求路径和映射逐行对比。这个问题和代码逻辑半毛钱关系都没有纯粹是路径对齐问题。5.2 JDBC驱动找不到出现java.lang.ClassNotFoundException: com.mysql.jdbc.Driver九成是JAR包没进WEB-INF/lib。另一成的可能是在jdbc.properties里写成了全角标点或多余空格导致驱动类名加载失败。解决办法是把JAR包放到位重新清理Tomcat的临时缓存再重启。注意有些IDE不会自动同步lib目录新增文件需要手动执行一次Clean操作。5.3 中文乱码乱码问题通常不是显示层的问题而是贯穿了请求、转码、数据库存储三条链路。从Tomcat的server.xml里设置URIEncodingUTF-8到JSP页面头部写pageEncodingUTF-8再到数据库连接URL里的characterEncodingutf8任何一处断掉都会乱码。判断断点位置有个方法如果查询条件里的中文乱多半是请求编码问题如果页面上展示的历史名称乱多半是数据库读取出错如果插入数据库之前就乱则优先检查JSP源码文件保存的编码格式。这三条链路你顺一遍绝大多数乱码都能解决。5.4 MySQL 8.0的驱动类名和SSL警告MySQL 8.0时代驱动类名变成了com.mysql.cj.jdbc.Driver连接URL里建议加上useSSLfalse和serverTimezone前者是为了避免没有配置证书时打印一堆SSL警告后者是为了解决时区偏移。很多旧配置直接沿用了com.mysql.jdbc.Driver不是不能运行而是会触发警告并有可能在特定场景下行为异常。我的建议是在升级数据库时顺便把驱动配置更新一遍不要省这一步。5.5 端口占用和Tomcat启动失败Tomcat默认端口是8080如果被其他进程占用启动时日志会写Port already in use。解决方式是在配置文件的Connector节点里改端口或者找出占用进程结束它。Windows下常用netstat -ano | findstr 8080 taskkill /PID 进程号 /F这里重点提示改Tomcat端口不要只改一处server.xml里可能有多个Connector包括HTTP和AJP生产环境还要考虑防火墙放行对应端口。5.6 一次完整排查链路示例有一次我给某台机器部署这个系统启动正常首页打开也正常但是一点查询按钮就报500错。我没有直接改代码而是先看了Tomcat的logs/localhost.yyyy-MM-dd.log发现异常栈里写着SQLException: Unknown column s.turnover_rate。这明显是SQL里引用了一个表中不存在的字段。接着我打开数据库客户端执行DESC daily_kline;发现字段名是turnoverrate不是turnover_rate。问题的根因一下就清楚了源码是按下划线命名写的但初始SQL脚本里建表时用了不带下划线的字段名。两点对齐之后我把SQL里的列名改成和数据库一致重新发布问题就消失了。这类问题看起来吓人但只要按照“看日志、看表结构、对照字段名”三步走十几分钟就能定位不要一上来就怀疑项目不能跑。6. 从跑通到改造成自己的系统三个可落地的扩展方向6.1 策略参数模块化很多人的第一个需求就是“想换策略”。直接在源码里改数字改完就乱了下次想切回原策略又得翻代码。更好的做法是把参数配置做到数据库表里比如strategy_params表保存均线周期、评分权重、筛选阈值页面提供一个管理表单用户改了参数之后查询逻辑每次从数据库读取。这样做的好处是策略调整不用重新编译省下的时间非常可观。改造时只需在Service层增加一个读取策略的逻辑代码上下文保持不变页面和DAO层的改动非常少。我实际改造时大概花了半个小时之后调参体验提升了一个档次。6.2 增加新指标和数据源如果觉得三因子评分不够用可以往daily_kline表增加字段比如增加一个amplitude字段记录振幅再把新指标接入ScoreCalculator。增加字段不是难题真正要处理的是历史数据怎么补齐。这里建议最好在数据库脚本里预留备用字段或者做一套独立的CSV导入工具避免后续全部手工改数据。如果你是自建学习环境不建议用真实生产环境的口径去采集大量历史行情重点在于把流程跑通用模拟数据或者少量公开测试数据就足够验证项目的业务闭环。对系统本身而言它的价值在于展示如何从数据库到页面再到参数配置形成完整的选取链路。6.3 经验与注意事项写这类JSP系统的核心经验我总结成一句话先稳定数据库再理解部署最后改逻辑。数据库没跑通之前所有页面上的报错都会指向同一个假象“源码有问题”。实际上源码通常没有问题问题大多出在环境匹配和数据格式上。调试的时候要舍得花时间看异常堆栈不要只看最后一行。顶部的Caused by才是罪魁祸首你从下往上看才能找到真正的原因。这个习惯适用于任何Java Web项目不止选股系统。最后再分享一个我个人的操作习惯每次拿到这类“源码数据库调试部署”交付包我都会先把数据库脚本另存一份然后在副本里执行和修改。这样做既能保留原始参考样例又能放心大胆地加自己的策略参数。等系统稳定跑起来之后再决定要不要把这些改动合并回主项目。这种留一手的习惯在调试阶段能帮你避免很多重复劳动也让你在把项目改坏的时候永远有一条回头路。