简介这份Java股票源码面向股票交易系统开发者与运营团队提供一套可直接部署的完整交易平台方案覆盖新股申购、融资融券、股票配资与打新股等业务场景。系统采用Spring后台与Vue前端架构分电脑网页端与手机双端支持打包APP并配有代理独立后台与单独新股后台新增AI智能推荐股票、VIP股票、充值通道码、对冲设置、图形验证码及自定义追加保证金比例等功能适合二次开发或包网式合作。资源包共253个文件以js脚本、png图片、css样式、ttf与woff字体、svg图标及html页面为主另含sql数据库脚本、jar包与docx说明文档压缩包约133.7MB目录结构清晰便于按模块查阅。目前已有101人学习下载可帮助读者快速理解交易系统的前后端组织方式、新股与两融业务实现思路及运营后台的扩展设计。1. 一套 Java 股票交易系统源码为什么我把它的新股申购模块单独拆出来看前阵子有个做券商外围系统的朋友甩给我一份 Java 股票源码标题写得很长——2024 全新 UI、打新股、两融双融、新股申购、股票交易、股票配资、融资融券全都有。我第一反应是「又一个把菜单堆满的 Demo」但翻到新股申购和融资融券这两个模块时发现它的账户资金冻结逻辑写得比很多教学项目扎实值得单独拆出来讲。这套源码本质是一个基于 Java 的股票交易模拟系统覆盖了普通买卖、新股申购、融资融券两融三条业务线前端是 2024 年重做的 UI。它适合两类人一是想学交易系统账户模型怎么设计的后端开发者二是需要一套能跑通申购、配资、两融流程做课程设计或内部演示的团队。下面我不吹它多完整只讲我实际拆过之后哪些地方能直接抄、哪些参数必须改、哪些坑我踩过。2. 账户与资金模型先搞懂冻结、可用、总资产三者的关系2.1 为什么交易系统的钱不能只用一个余额字段新手写股票程序最容易犯的错是给账户表只放一个balance字段买就减、卖就加。真跑起来立刻翻车你挂了个买单还没成交这笔钱到底算不算你的新股申购要冻结资金冻结期间能不能拿去融资这些问题一个balance根本答不了。这套源码用的是「总资产 可用资金 冻结资金 持仓市值」的拆分模型对应到表结构上至少有三个关键字段available_amount可用、frozen_amount冻结、total_amount总资产通常是前两者加持仓市值算出来的冗余字段。我一般会建议再补一个frozen_detail流水表记录每一笔冻结的来源申购冻结、挂单冻结、保证金冻结否则对账时就是黑匣子。选型上它没有用分布式事务而是单库本地事务加乐观锁版本号这对单机演示和中小规模够用。如果你要上多节点这套模型得换成基于冻结流水的最终一致性方案那是另一个话题。2.2 建表与核心字段落地下面是我从源码里整理并简化后的账户与冻结流水建表语句字段名做了通用化处理可以直接拿去改-- 资金账户表一个用户对应一条主账户记录 CREATE TABLE t_fund_account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 用户ID, available_amount DECIMAL(18,2) NOT NULL DEFAULT 0 COMMENT 可用资金, frozen_amount DECIMAL(18,2) NOT NULL DEFAULT 0 COMMENT 冻结资金, total_amount DECIMAL(18,2) NOT NULL DEFAULT 0 COMMENT 总资产(冗余,便于查询), version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user (user_id) ) COMMENT 资金账户; -- 冻结流水表每一笔冻结/解冻都要留痕 CREATE TABLE t_frozen_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, biz_type TINYINT NOT NULL COMMENT 1申购 2挂单 3保证金, biz_no VARCHAR(64) NOT NULL COMMENT 业务单号,用于幂等, amount DECIMAL(18,2) NOT NULL COMMENT 冻结金额,负数表示解冻, status TINYINT NOT NULL DEFAULT 0 COMMENT 0冻结中 1已解冻, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_biz (user_id, biz_no) ) COMMENT 资金冻结流水;逻辑说明t_fund_account用version做乐观锁扣款时UPDATE ... SET available_amount available_amount - ?, version version 1 WHERE user_id ? AND version ?更新影响行数为 0 就重试。t_frozen_flow的biz_no是幂等关键——同一笔申购单重复提交时靠它去重避免重复冻结。参数上DECIMAL(18,2)是金额字段的常见选择别用FLOAT浮点误差在对账时能让你加班到天亮。提示total_amount是冗余字段每次资金变动后要么同步更新要么干脆不存、查询时实时算。我倾向后者少一个不一致的来源。3. 新股申购模块从冻结资金到中签解冻的完整链路3.1 申购流程拆成四步每步都要能回滚打新股的业务链路比普通买卖长源码里把它拆成了四步校验申购额度 → 冻结申购资金 → 生成申购委托 → 等待中签结果处理。这四步任何一步失败前面的冻结都要能回滚否则用户的钱就卡在系统里了。第一步校验额度要同时看两个东西账户可用资金够不够以及该市场沪市/深市的申购市值门槛够不够。源码里市值门槛是配置项不是写死的这点做得对——不同时期规则会变写死就得改代码重新发版。第二步冻结走的就是上面t_frozen_flow那套。第三步生成委托单状态置为「已申报」。第四步是异步的等中签结果回来后中签部分扣款转持仓未中签部分解冻退回可用。3.2 申购核心代码与参数说明这是我从源码里抽出来的申购主流程去掉了业务无关的日志和校验分支Service public class IpoApplyService { Autowired private FundAccountMapper fundAccountMapper; Autowired private FrozenFlowMapper frozenFlowMapper; /** * 新股申购 * param userId 用户ID * param stockCode 新股代码 * param price 发行价 * param qty 申购数量(股),必须是500的整数倍 */ Transactional(rollbackFor Exception.class) public String apply(Long userId, String stockCode, BigDecimal price, Integer qty) { // 1. 数量校验沪深两市申购单位不同,这里按500股一手 if (qty null || qty 0 || qty % 500 ! 0) { throw new BizException(申购数量必须是500股的整数倍); } BigDecimal needAmount price.multiply(BigDecimal.valueOf(qty)); // 2. 乐观锁扣减可用资金,失败则重试(重试逻辑在外层) int rows fundAccountMapper.freeze(userId, needAmount); if (rows 0) { throw new BizException(可用资金不足或账户繁忙,请重试); } // 3. 写冻结流水,bizNo保证幂等 String bizNo IPO System.currentTimeMillis() userId; FrozenFlow flow new FrozenFlow(); flow.setUserId(userId); flow.setBizType(1); flow.setBizNo(bizNo); flow.setAmount(needAmount); frozenFlowMapper.insert(flow); // 4. 生成申购委托(此处省略委托表写入) return bizNo; } }逻辑说明freeze方法内部就是那条带version的 UPDATE把available_amount减掉、frozen_amount加上。参数qty强制 500 整数倍是硬规则源码里放在 Service 层校验我建议再在数据库加个 CHECK 或应用层 DTO 注解双保险。bizNo的拼法用时间戳加用户 ID简单但够用如果并发极高时间戳可能撞换成雪花 ID 更稳。3.3 中签结果处理解冻和扣款要分开算中签结果回来后的处理源码里是一个定时任务扫申购委托表。逻辑是对每笔已申报的申购拿到中签数量中签部分把冻结资金转成持仓成本未中签部分解冻回可用。这里有个容易忽略的点中签数量可能是 0也可能小于申购数量所以解冻金额 冻结金额 - 中签数量 × 发行价。我见过有人直接全额解冻再重新扣款结果中间出现资金空窗用户趁机提现对账直接崩。源码没犯这个错它是一笔事务里同时完成「部分解冻 部分扣款」。参数上中签结果通常来自外部文件或接口源码里留了一个IpoResultParser接口具体实现按券商返回格式自己写。这个设计是对的因为不同数据源的格式差异很大硬编码解析逻辑后期维护成本极高。4. 融资融券模块保证金比例和强平线怎么设才不炸4.1 两融的账户模型比普通账户多一层融资融券不是简单的「借钱买股」它有一套独立的信用账户体系。源码里给每个开通两融的用户建了一个信用账户记录credit_total授信额度、margin_used已用保证金、debt_amount负债金额、maintain_ratio维持担保比例。维持担保比例是两融的核心指标公式是现金 持仓市值/融资负债 融券市值。这个比例低于平仓线系统就要强制平仓。源码里平仓线默认设 130%警戒线 150%这两个值是可配置的我建议别改因为它们是行业常见参考值改低了风险敞口变大改高了用户体验差。4.2 保证金计算与强平触发代码public class MarginService { /** 警戒线 */ private static final BigDecimal WARN_RATIO new BigDecimal(1.5); /** 平仓线 */ private static final BigDecimal CLOSE_RATIO new BigDecimal(1.3); /** * 计算维持担保比例 * param cash 信用账户现金 * param marketValue 持仓市值 * param debt 总负债 */ public BigDecimal calcMaintainRatio(BigDecimal cash, BigDecimal marketValue, BigDecimal debt) { if (debt.compareTo(BigDecimal.ZERO) 0) { return new BigDecimal(999); // 无负债,返回一个极大值 } return cash.add(marketValue).divide(debt, 4, RoundingMode.HALF_UP); } /** * 判断是否需要强平 */ public boolean needForceClose(BigDecimal ratio) { return ratio.compareTo(CLOSE_RATIO) 0; } /** * 判断是否触发警戒 */ public boolean needWarn(BigDecimal ratio) { return ratio.compareTo(WARN_RATIO) 0 ratio.compareTo(CLOSE_RATIO) 0; } }逻辑说明calcMaintainRatio里对无负债情况返回 999 是个取巧做法避免除零但更严谨的做法是返回null或单独状态标记因为 999 参与后续比较时可能产生误导。divide的精度设 4 位、舍入用HALF_UP这是金融计算的常见配置别用默认的HALF_EVEN对账时容易和预期差一分钱。强平触发后源码是按持仓市值从大到小依次卖出直到维持担保比例回到警戒线以上。这个顺序可以调我一般会优先卖流动性好的标的避免卖不出去反而扩大风险。4.3 配资和两融的区别别混在一个模块里标题里同时出现了「股票配资」和「融资融券」这俩不是一回事。两融是持牌业务走信用账户有严格的保证金和强平规则配资更像民间借贷资金来源和风控逻辑完全不同。源码里把它们做成了两个独立模块共用资金账户但走不同的业务流水这个拆分是对的。如果你只关心两融配资模块可以直接不部署不影响主流程。但要注意两个模块如果共用t_frozen_flowbiz_type要区分开否则对账时冻结来源分不清。5. 避坑与排查我拆这套源码时踩过的五个坑5.1 现象申购时提示资金不足但账户明明有钱原因可用资金和总资产是两个字段用户看到的是总资产含持仓市值但申购只能用可用资金。源码前端早期版本把总资产显示在显眼位置可用资金藏在二级页面导致误解。解决前端把可用资金放在申购页顶部或者在提交前用 tooltip 明确提示「本次申购将冻结 XX 元可用资金」。后端不用改这是展示层问题。5.2 现象同一笔申购重复提交冻结了两笔钱原因网络抖动导致用户重复点击或者前端没做防重后端也没做幂等。源码的biz_no幂等设计在但如果biz_no是每次请求新生成的幂等就失效了。解决biz_no要由前端生成并随请求带上或者后端用「用户 ID 股票代码 申购日期」做唯一键。我一般会在t_frozen_flow上加唯一索引uk_user_biz (user_id, biz_no)重复插入直接报错回滚。5.3 现象中签解冻后总资产对不上原因total_amount冗余字段没有同步更新或者解冻时只改了frozen_amount没改available_amount。解决要么放弃冗余字段实时算要么在每次资金变动的事务里强制更新total_amount。我倾向实时算少一个不一致来源。如果非要冗余加个定时对账任务每天扫一遍差异。5.4 现象强平任务跑了但持仓没卖出去原因强平逻辑依赖行情接口拿最新价行情接口超时或返回空导致计算出的市值不准或者卖出委托被交易所拒绝跌停无法卖出。解决强平前先校验行情可用性拿不到最新价就用昨收价兜底并告警。跌停卖不出是客观限制系统要做的是记录失败原因并重试而不是静默失败。源码里重试次数是 3 次间隔 5 秒这个参数可以按标的流动性调整。5.5 现象两融账户的维持担保比例算出来是负数原因负债字段被写成了负数或者现金字段被重复扣减。常见于手动改库或测试数据造得不对。解决在calcMaintainRatio入口加断言现金和市值不能为负负债不能为负。测试环境造数据时用脚本别手动 UPDATE。源码里没加这个断言我拆的时候补上了。6. 进阶技巧用单元测试锁住资金守恒这条底线拆完这套源码我最大的习惯是给它补一组资金守恒的单元测试。交易系统里最怕的不是功能少而是钱算错了还看不出来。我的做法是任何涉及资金变动的操作测试里都断言「操作前总资产 操作后总资产」冻结、解冻、扣款、强平一个都不放过。Test public void testFreezeKeepsTotalAssetConsistent() { // 准备:账户初始可用10000,冻结0 FundAccount before fundAccountMapper.selectByUserId(1L); BigDecimal totalBefore before.getAvailableAmount().add(before.getFrozenAmount()); // 执行:冻结3000 ipoApplyService.apply(1L, 600000, new BigDecimal(10.00), 300); // 断言:总资产不变,可用减3000,冻结加3000 FundAccount after fundAccountMapper.selectByUserId(1L); BigDecimal totalAfter after.getAvailableAmount().add(after.getFrozenAmount()); assertEquals(0, totalBefore.compareTo(totalAfter)); assertEquals(0, after.getAvailableAmount().compareTo(new BigDecimal(7000))); assertEquals(0, after.getFrozenAmount().compareTo(new BigDecimal(3000))); }这段测试跑通至少说明冻结逻辑没把钱弄丢。我还会再加一组并发测试用多线程同时申购验证乐观锁重试和幂等是否生效。参数上并发线程数设 50 就够暴露大部分问题跑 1000 次循环看最终总资产是否守恒。从那以后我每次拿到任何一套交易类源码第一件事就是补资金守恒测试跑不通的模块直接不看。这套 Java 股票源码在补完测试后新股申购和两融两条线是能站住的UI 和配资模块看个人需求取舍。希望帮到你。本文还有配套的精品资源点击获取