尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
JavaWeb合同管理系统开发实战:建表、鉴权、状态机与性能优化
简介面向JavaWeb初学者和合同管理信息化项目开发者的一套完整源码资源基于Servlet、JSP、JSTL及MySQL等技术覆盖合同信息录入、修改、删除、多条件查询、执行记录、数据分析、权限管理、报表导出与到期提醒等功能适合课程设计、毕业设计或企业合同模块二次开发参考。压缩包共941个文件约16.18MB主要包含html页面、css样式、js与jsp动态页面、java与class源码、jar依赖库、数据库db文件及xml配置等类型较全便于直接导入IDE运行与调试验证。已有333人学习浏览整体代码结构清晰附带的图片、脚本和数据库文件可供完整跑通系统。通过阅读源码可快速掌握合同信息分页查询、Excel导出、验证码登录、角色权限过滤等实现思路了解Action、DAO、Bean等分层设计后也能便捷地在此基础上新增合同统计报表或提醒推送逻辑。1. 合同管理系统 JavaWeb从建表到跑通路径其实很固定合同管理系统在 JavaWeb 和 java web 这个方向里一直是最常青的题目之一。随便搜“javaweb 项目完整案例 mysql”十个结果里三四个是合同管理或 OA 里的合同模块原因很简单它表面是增删改查底层却要把金额精度、状态机、审批权限、附件留存、打印兼容这些小翻车点全部串起来。这篇笔记就顺着“合同管理系统新版_javaweb_合同系统 WEB”这个标题按真正给企业做系统的顺序——建表、登录鉴权、状态流转、踩坑排查、性能优化、编号与导出——把可复现的落地路径讲清楚。适合正在找 javaweb 项目完整案例做毕业设计或入职项目的人也适合想把 Excel 管合同升级成 Web 系统的同学。2. 建表与登录鉴权先把合同系统的地基打牢企业里的合同管理系统百分之八十的翻车都不是因为前端页面丑而是后端的表结构一开始就没想清楚。常见做法是先定五张核心表再写登录鉴权如果反过来先写接口再补表做到审批流的时候大概率要回头改字段。这五张表分别是用户表、合同主表、附件表、审批记录表和操作日志表它们各管一段用户管权限边界合同管业务数据附件管证据审批表管过程日志表管审计。2.1 五张核心表搞定合同主数据先看用户表。合同系统的用户不需要太多字段但部门编码一定要留后面做自动编号时要用它拼前缀。CREATE TABLE sys_user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(50) NOT NULL COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, real_name VARCHAR(50) DEFAULT NULL COMMENT 姓名, dept_code VARCHAR(20) DEFAULT NULL COMMENT 部门编码用于合同编号前缀, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里 password 用 VARCHAR(100)是因为 BCrypt 加密出来的串是 60 位50 位根本存不下。很多新写 JavaWeb 项目的人喜欢给 password 留 255 位没问题但 50 位一定不够用。dept_code 是给第 6 章编号规则预留的建表时就要想好。接着是合同主表这是整套系统里最重要的表字段不能省。CREATE TABLE contract ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, contract_no VARCHAR(64) NOT NULL COMMENT 合同编号唯一, contract_name VARCHAR(255) NOT NULL COMMENT 合同名称, party_a VARCHAR(255) NOT NULL COMMENT 甲方名称, party_b VARCHAR(255) NOT NULL COMMENT 乙方名称, amount DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 含税金额单位元, currency VARCHAR(3) NOT NULL DEFAULT CNY COMMENT 币种, sign_date DATE DEFAULT NULL COMMENT 签订日期, effective_date DATE DEFAULT NULL COMMENT 生效日期, expiry_date DATE DEFAULT NULL COMMENT 失效日期, status VARCHAR(20) NOT NULL DEFAULT DRAFT COMMENT 状态DRAFT/APPROVING/EFFECTIVE/EXPIRED/TERMINATED, creator_id BIGINT NOT NULL COMMENT 创建人ID, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 0未删 1已删, PRIMARY KEY (id), UNIQUE KEY uk_contract_no (contract_no), KEY idx_status (status), KEY idx_expiry_date (expiry_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT合同主表;这里有几个容易被忽略的点。contract_no 加唯一索引是为了防止并发下生成重复单号status 用 VARCHAR 而不是 TINYINT因为项目联调时打开数据库一眼就能看懂这条合同在哪个状态省去翻代码对照枚举。amount 用 DECIMAL(18,2)合同金额到亿级也够用float 和 double 在金额计算上谁用谁吃亏。party_a 和 party_b 直接存文本不要存客户表 ID——合同当事人未必是系统用户可能是一个没录入系统的外部公司存 ID 会导致合同查不到名称。附件表和审批记录表是合同系统的两个“证据表”。CREATE TABLE contract_attach ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, contract_id BIGINT NOT NULL COMMENT 合同ID, file_name VARCHAR(255) NOT NULL COMMENT 原始文件名, file_path VARCHAR(500) NOT NULL COMMENT 存储相对路径, file_size BIGINT NOT NULL DEFAULT 0 COMMENT 字节数, version INT NOT NULL DEFAULT 1 COMMENT 附件版本号, uploaded_by BIGINT DEFAULT NULL COMMENT 上传人, uploaded_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 上传时间, PRIMARY KEY (id), KEY idx_attach_contract (contract_id, version) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT合同附件表;CREATE TABLE contract_approval ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, contract_id BIGINT NOT NULL COMMENT 合同ID, action_type VARCHAR(20) NOT NULL COMMENT SUBMIT/APPROVE/REJECT/CANCEL, approver_id BIGINT NOT NULL COMMENT 操作人ID, comment VARCHAR(500) DEFAULT NULL COMMENT 审批意见, created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 操作时间, PRIMARY KEY (id), KEY idx_approval_contract (contract_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT合同审批记录表;附件表特意加了 version 字段就是为了避免“覆盖旧扫描件”这种事故后面第 4 章会展开讲。contract_approval 只做插入不做更新审批记录属于不可变数据改了就没有审计意义。第五张表是操作日志表 contract_log字段为 id、contract_id、operator_id、field_name、old_value、new_value、created_at。它记录的是“谁在什么时候把哪个字段从什么值改成了什么值”比如合同金额从 10 万改成 12 万。注意 contract_log 和 contract_approval 是两回事审批记录管流转日志表管字段变化不能合并。2.2 登录鉴权Spring Security 还是自己写拦截器在 IDEA 里运行 JavaWeb 项目时合同系统最常见的登录鉴权方案有两种项目复杂度高、有 SSO 需求就上 Spring Security做内部系统或毕业设计自己写一个基于 token 的拦截器完全够用。我一般选后者原因很实际合同系统的权限模型简单不是所有业务人员都能审批合同登录后判断一下 user 角色就够了不值得把 Spring Security 那一整套过滤器链搬进来。拦截器核心代码如下。/** * 登录拦截器校验请求头里的 Authorization token */ public class LoginInterceptor implements HandlerInterceptor { private TokenService tokenService; public LoginInterceptor(TokenService tokenService) { this.tokenService tokenService; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 跨域预检请求直接放行否则浏览器 CORS 会卡在 OPTIONS if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !tokenService.verify(token)) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); return false; } request.setAttribute(userId, tokenService.getUserId(token)); return true; } }这段 preHandle 的逻辑很直白拿不到 token 就返回 401拿到了就解析出 userId 存进 request 里后面 Controller 直接取用。verify 里要做两件事一是验签名二是检查过期时间。TokenService 用 JWT 时要注意生成 token 时把 userId 放进 claim过期时间建议设成 2 到 8 小时太短影响体验太长不安全。拦截器注册时也有讲究。Configuration public class WebConfig implements WebMvcConfigurer { Autowired private TokenService tokenService; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor(tokenService)) .addPathPatterns(/**) .excludePathPatterns(/login, /static/**, /favicon.ico, /error); } }excludePathPatterns 里的 /login 必须放行否则用户根本没机会登录/static/** 放行是为了让浏览器能加载 CSS、JS。很多人在 IDEA 启动 SpringBoot 后看到样式丢了第一反应是路径配错其实是静态资源被拦截器挡住了。把这两条配好登录鉴权这关就过了。3. 合同状态机与审批留痕让业务流转起来合同系统的核心不是表单而是状态。草稿可以被提交成审批中审批中可以被通过成已生效已生效可以到期成已过期或人工终止。如果这些状态判断散落在各个 Service 方法里后期加一个“已归档”状态你会发现自己要改十几个 if。更稳的做法是先定义状态机所有入口只认这一套流转规则。3.1 合同状态机草稿、审批中、已生效、已终止用枚举把状态和允许的流转路径封装在一起是 JavaWeb 项目里最常见的写法。/** * 合同状态机 */ public enum ContractStatus { DRAFT(草稿), APPROVING(审批中), EFFECTIVE(已生效), EXPIRED(已到期), TERMINATED(已终止); private final String desc; private static final MapContractStatus, SetContractStatus TRANSITIONS new EnumMap(ContractStatus.class); static { // 只有明确配置的路径才允许流转 TRANSITIONS.put(DRAFT, EnumSet.of(APPROVING, TERMINATED)); TRANSITIONS.put(APPROVING, EnumSet.of(EFFECTIVE, DRAFT)); TRANSITIONS.put(EFFECTIVE, EnumSet.of(TERMINATED, EXPIRED)); TRANSITIONS.put(EXPIRED, EnumSet.of(EFFECTIVE)); TRANSITIONS.put(TERMINATED, EnumSet.of()); } ContractStatus(String desc) { this.desc desc; } public boolean canTransitionTo(ContractStatus target) { return TRANSITIONS.getOrDefault(this, Collections.emptySet()).contains(target); } public String getDesc() { return desc; } }状态转换表如下这张表应该在设计评审时直接拿给业务方确认。当前状态允许流转到触发动作DRAFTAPPROVING提交审批DRAFTTERMINATED作废APPROVINGEFFECTIVE审批通过APPROVINGDRAFT驳回EFFECTIVETERMINATED手动终止EFFECTIVEEXPIRED到期自动触发EXPIREDEFFECTIVE续签TERMINATED无终态用 EnumMap 的好处是新增状态时只改这一个枚举不需要去每个 Service 里补判断。EXPIRED 这个状态一般不是用户点的而是定时任务扫描 expiry_date 自动推过去的所以 EFFECTIVE 和 EXPIRED 之间不要提供用户操作入口。3.2 审批链路与操作留痕审批通过这个动作是并发风险最高的地方。两个审批人同时打开同一份合同都点了“通过”如果代码只是先查询再更新状态就会被覆盖两次。常见做法是给查询加行锁再配合状态条件更新。/** * 审批通过 */ Transactional(rollbackFor Exception.class) public void approve(Long contractId, Long approverId, String comment) { // select ... for update锁住合同行避免并发审批 Contract contract contractMapper.selectByIdForUpdate(contractId); if (contract null) { throw new BusinessException(合同不存在); } if (!contract.getStatus().canTransitionTo(ContractStatus.EFFECTIVE)) { throw new BusinessException(当前状态不允许审批通过); } // 更新主表状态 contract.setStatus(ContractStatus.EFFECTIVE); contractMapper.updateById(contract); // 写入审批记录只增不改 ContractApproval approval new ContractApproval(); approval.setContractId(contractId); approval.setActionType(APPROVE); approval.setApproverId(approverId); approval.setComment(comment); contractApprovalMapper.insert(approval); }这里有几个细节。Transactional 必须加因为 update 和 insert 要在一个事务里否则状态改了审批记录没写进去后面审计对不上账。selectByIdForUpdate 的锁要等事务提交才释放所以这个方法里不要做耗时操作比如调远程接口或者发邮件。canTransitionTo 先拦一次update 时再兜底一次双保险。操作留痕这块我在 Service 层做了一个字段对比的公共方法接收旧对象、新对象、操作人 ID遍历指定字段值有变化就向 contract_log 插一条记录。这个方法不复杂但非常实用业务方来问“这个价格谁改的”你只需要查一张表就能回答。不要用 AOP 做全字段自动记录太重的切面在黑盒出问题时反而难排查。4. 合同管理避坑日期、金额、附件、并发、打印 5 个高频问题这个方向做得越久越发现翻车的永远是那几个点。我把它们按出现频率排了个序每个都按现象、原因、解决的思路写清楚照着排查能省一半时间。4.1 金额计算必须用 BigDecimal别用 double现象合同金额做折扣或者累计时页面显示 0.999999999 这种诡异数字。原因double 和 float 是二进制浮点数0.1 在二进制里是无限循环小数运算后必然有误差。合同金额是财务数据一个小数点错位轻则返工重则对不上账。解决数据库字段用 DECIMAL(18,2)Java 代码里所有金额计算都用 BigDecimal。BigDecimal fee request.getAmount().setScale(2, RoundingMode.HALF_UP); if (fee.compareTo(BigDecimal.ZERO) 0) { throw new BusinessException(合同金额必须大于 0); }注意这里用 compareTo 而不是 equals因为 BigDecimal 的 equals 会认为 1.0 和 1.00 不相等而合同金额从页面传过来经常是 100.00 和 100.0 混着来。compareTo 只比数值才是业务想要的逻辑。4.2 合同日期范围校验别只靠前端控件现象前端日期选择器用了结束日期不能早于开始日期但测试直接调接口提交expiry_date 比 effective_date 还早系统照样保存成功。原因前端限制只是体验不是安全边界。接口层没有做后端校验Postman 一调就绕过。解决在 Service 层入口统一校验。LocalDate effective request.getEffectiveDate(); LocalDate expiry request.getExpiryDate(); if (effective ! null expiry ! null expiry.isBefore(effective)) { throw new BusinessException(失效日期不能早于生效日期); } if (expiry ! null expiry.isBefore(LocalDate.now())) { throw new BusinessException(失效日期不能早于今天); }还有一个容易忽略的点Java 8 的 LocalDate 不携带时区如果服务器和业务方不在同一时区日期可能差一天。用 DateTimeFormatter.ofPattern(yyyy-MM-dd) 解析字符串时没有时区问题但如果你在代码里 new Date() 转 LocalDate就要注意时区转换。我一般会写一个 DateUtils 统一处理避免业务层各写各的。4.3 附件改版后要保留历史版本别直接覆盖现象合同扫描件重新上传后之前的文件在服务器上找不到了业务方要求恢复旧版改不了。原因实现时用固定路径存附件比如 /upload/contract.pdf第二次上传把同名文件覆盖了。这种设计在小项目里很常见但合同附件是证据必须留痕。解决附件表按插入方式写上传一次插入一条记录路径里带 UUID不重名。attach/2024/12/{contractId}/{uuid}.pdf同时把 version 字段递增合同主表只保存“当前生效附件版本号”历史版本全部留在附件表里。下载接口加一个 version 参数默认取最新版本业务方要调旧版也能给。4.4 审批并发兜底状态条件更新是最后一道防线现象两个审批人同时点“通过”后台生成了两条审批通过记录合同状态从前端看没问题但操作日志和审批记录对不上。原因只做了 select 判断状态update 时没有把旧状态放进 WHERE 条件两个人先后查到同一份 APPROVING 合同各自都执行了更新。解决更新语句里带上状态条件用影响行数判断是否被他人抢先处理。int rows contractMapper.updateStatusByCondition( contractId, ContractStatus.APPROVING, ContractStatus.EFFECTIVE ); if (rows 0) { throw new BusinessException(合同状态已变化请刷新后再试); }对应的 SQL 是这样的。UPDATE contract SET status #{targetStatus}, updated_at NOW() WHERE id #{contractId} AND status #{oldStatus};影响行数为 0 时不要继续往下走直接抛异常。用悲观锁场景里这两个机制可以共存select for update 锁住行update 条件更新再兜底一次双保险总比单保险稳。4.5 WEB 页面 PDF 打印打印机兼容性最坑现象合同列表页点击打印打印预览里内容挤成一团或者没有页边距打印出来最后一列被截断。原因页面没用 media print 样式浏览器打印时把屏幕样式直接搬过去了。屏幕上是横向布局打印是纵向纸张自然错位。解决给打印单独写一套样式。media print { .no-print { display: none !important; } body { font-size: 12pt; } .contract-content { width: 100%; padding: 0; } page { margin: 15mm; } }把不需要打印的按钮、搜索栏、分页条都加上 no-print 类。如果业务方要求直接出 PDF而不是用户自己点浏览器打印那就得走服务端模板转 PDF 的方案网页打印只能作为辅助。我一般会在系统里保留两套在线预览页面用屏幕样式另配一个 print 版本专门出纸质件。5. 接口与分页性能让 JavaWeb 合同系统跑得更稳合同数据量一大列表接口最先扛不住。我接手过一个跑了三年的合同系统contract 表三十万行列表页打开要四秒。排查下来不是 SQL 多复杂而是查询条件没走索引加上大量 N1 查询。这章把排查顺序和参数设定讲透。5.1 列表页慢查询的排查顺序第一步是打开 MyBatis 的 SQL 日志看接口这段时间到底执行了什么。logging: level: com.example.contract.mapper: debug配置之后控制台会打印每条 SQL 和参数。看到类似反复执行同一类 SELECT 的就是典型 N1查出几十条合同再循环查每一条的附件或审批记录。解决思路是一次性把附件按 contract_id 集合查出来内存里组装。select idselectByContractIds resultTypeContractAttachVO SELECT contract_id, id, file_name, version FROM contract_attach WHERE contract_id IN foreach collectionids itemid open( separator, close) #{id} /foreach /select第二步看查询条件有没有对索引列做函数操作。常见慢查询是这样写的-- 慢对索引列套函数索引失效 WHERE DATE(effective_date) 2024-01-01;改成范围条件-- 快直接走 idx_expiry_date WHERE effective_date 2024-01-01 AND effective_date 2025-01-01;很多新人踩坑是因为传参方便把整个日期字符串传给 DATE 函数自以为没问题实际全表扫描。第三步看分页 count 是不是太大如果业务只需要前一百条limit 要写清楚别让数据库做无用功。5.2 分页参数怎么定页大小与排序字段JavaWeb 项目里分页常见做法是用 PageHelper 或 MyBatis-Plus 的分页插件代码写起来几乎一样。PageHelper.startPage(pageNum, pageSize); ListContractVO list contractMapper.pageContracts(query); PageInfoContractVO page new PageInfo(list);注意 startPage 只对接下来第一条查询生效所以 common 项目里不要把它和复杂业务逻辑混着写容易让分页作用到错误 SQL 上。pageNum 从 1 开始pageSize 默认 20前端只给 10、20、50 三档不允许用户输入 9999。排序字段不要直接拼 SQL用一个白名单映射控制。private static final MapString, String SORT_MAP Map.of( createTime, created_at, amount, amount, signDate, sign_date );前端传排序字段名时只接受白名单里的 key排序方向只允许 asc/desc拼到 order by 里。直接拼接排序字段是 SQL 注入的高发点合同列表这种接口容易被扫描器盯上白名单是成本最低的防护。6. 进阶技巧合同编号自动生成、导出 Excel 和省心的验证方式系统做到能跑只是第一步真正常被夸奖的往往是细节。这里说三个我在后续版本里反复用到的小技巧。6.1 合同编号自动生成流水号不重复合同编号必须有规则而且要保证并发不重复。我常用前缀加流水号的设计。段示例说明业务前缀HT合同标识年份2024签订年份部门编码FIN财务部合同流水号0001同年同部门内递增public String nextContractNo(Long userId) { String year String.valueOf(LocalDate.now().getYear()); String deptCode userMapper.getDeptCodeByUserId(userId); String prefix HT- year - deptCode -; // counter 表里放同一前缀的当前值SELECT ... FOR UPDATE 保证并发不重复 Long seq counterMapper.nextSeq(prefix); // 流水号补零至少 4 位 return prefix String.format(%04d, seq); }counter 表是专门用来记流水号的字段就三个前缀、当前值、更新时间。每次生成单号时把当前值加一用行锁保证并发下不会拿到同一个号。流水号超过 9999 时String.format(%04d) 会自动扩展成 5 位不用改代码。注意编号里的年份用的是签订日期而不是当前日期补录合同时才不会出现去年的合同挂着今年编号。6.2 导出 Excel 别一次性加载全表合同清单导出是最容易 OOM 的功能。全表数据一次性查出来放到内存里再写字板流三五十万行直接卡死。我一般用 EasyExcel 的流式写数据源用分页批量查询。GetMapping(/export) public void export(HttpServletResponse response) throws IOException { response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setCharacterEncoding(UTF-8); // 分页查询每 5000 条一批写入 EasyExcel.write(response.getOutputStream(), ContractExcelRow.class) .sheet(合同清单) .doWrite(() - contractMapper.selectPageForExport(pageNum, 5000)); }EasyExcel 底层只在内存保留一行写一行不会被整张表拖死。导出接口最好加个异步任务导出完成后发提醒而不是让用户干等页面转圈。最后说一个我自己的习惯每次改完合同状态机或审批流程我都用一份固定测试合同从头到尾走一遍草稿提交审批、审批通过、到期转已终止、再试试非法流转被拦截。这套手工回归路径五到十分钟比任何自动化脚本都直观。踩过太多次自认为改好了、结果审批链路上一个状态没配对的坑才开始养成的这个习惯。做合同系统页面好不好看是次要的每一步操作之后都能说清“这份合同在哪、谁批的、为什么金额对不上”才是价值所在。希望这条手动回归路径帮你也少踩几个坑。本文还有配套的精品资源点击获取
RELATED

相关推荐

LTspice电压源设置全解:从直流到正弦波,信号发生器用法一文讲透

LTspice电压源设置全解:从直流到正弦波,信号发生器用法一文讲透

很多人第一次在LTspice里想找一个正弦波电压源时都会愣一下:明明工具栏上摆着电压源符号,点进去却只有一个DC Value输入框,正弦波的选项到底藏在哪里?我第一次用的时候也在这个界面上绕了十几分钟,后来才明白&#xff…

📅 2026/10/7 12:58:04
端侧3TOPS NPU如何跑出15ms人脸识别?全链路优化实战

端侧3TOPS NPU如何跑出15ms人脸识别?全链路优化实战

做端侧AI的同学应该都有过这种纠结:拿着一个号称3TOPS算力的芯片,心里其实没底。这个数字到底能跑多大模型?能不能带动人脸识别?延迟会不会翻车?每次看到厂家宣传页上那些漂亮的帧率数字,自己上手一测却是另…

📅 2026/10/7 12:58:04
无感BLDC反电动势检测实战:从比较器电路到三段式启动

无感BLDC反电动势检测实战:从比较器电路到三段式启动

1. 先搞清楚一件事:无感BLDC到底在“感”什么很多人一听到“无感无刷电机”,第一反应是FOC、滑模观测器、龙伯格观测器这些词。实际上,在电动工具、水泵、散热风扇、无人机电调这些出货量最大的场景里,真正扛起大梁的技术反而更朴…

📅 2026/10/7 12:58:04
MORE NEWS

更多资讯

📰

多模型时代AI网关架构设计与核心能力拆解

1. 多模型时代,应用架构正在经历什么1.1 从一个真实困境说起去年下半年,我帮一个做智能客服的朋友排查线上问题。他们的产品接了三家不同厂商的大模型:一家负责通用对话,一家专攻意图识别,还有一家处理多模态的图片理解…

📰

LSTM双色球预测源码深度解析:时序预测工程的实战边界

简介:基于LSTM的双色球中奖预测Python源码,为对彩票序列数据挖掘感兴趣的Python开发者及机器学习入门者提供了一套可运行的完整示例。项目依据任务化管理思路,通过Taskfile定义了数据下载、依赖安装、模型训练等清晰步骤,并针对红…

📰

claude code接入纯文本大模型,API Error: 400 Model only support text input 彻底解决方案:把 settings 改到 TaoToken

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

JavaWeb新闻发布系统源码拆解:Servlet+JSP三层架构与分页上传实战解析

简介:这是一套基于JavaWeb的新闻发布系统毕业设计完整资料包,面向计算机专业毕业生、Java Web学习者及需要实战项目的开发者。资源围绕可运行的源代码、数据库SQL脚本与毕业论文展开,覆盖新闻管理、栏目分类、评论互动、用户登录等核心功能&a…

📰

Linux运维:日志轮转与TaoToken API调用日志的自动化清理

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

OpenClaw与ComfyUI本地桥接部署:从自然语言到一键出图实战

最近有人问我,OpenClaw和ComfyUI这两个东西到底能不能在本地串成一个完整的工作流。答案是能,而且只要搭好了,体验比来回切界面舒服得多。OpenClaw这种本地智能体框架负责理解你的自然语言指令,ComfyUI负责把指令变成一张张图&…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬