JeecgBoot V3.9.3 刚完成 Spring Boot 4 架构升级，V3.9.5 很快跟进发布。这一版的重点不是零散修复，而是围绕低代码开发、AI 应用和企业集成能力做了一次集中增强：Online 表单覆盖更多真实业务场景，代码生成器模板更灵活，AI Flow 在模型、知识库和流程编排方面更完整，同时补上了分享 Token、访问限流、OpenAPI 日志等生产环境关心的能力。
Online 不再局限于简单表单
V3.9.5 的 Online 升级，核心价值在于让低代码表单更接近实际企业系统。
一方面，Online 表单新增多数据源支持。对于同时使用主业务库、报表库或外部数据服务的系统，这意味着表单不必把所有数据都搬到同一个库中才能完成展示和处理。可以根据业务边界选择数据来源，降低跨系统集成时的改造成本。
另一方面，外部填报能力适合审批申请、客户登记、供应商信息收集等场景。外部用户不一定需要进入完整后台，也可以通过独立入口提交数据。落地时仍然要重点设计身份校验、数据权限、重复提交和敏感字段保护，不能因为入口变简单就放松安全要求。
可以这样规划一个外部填报接口的最小保护配置。下面的配置是实践示例，具体字段名需要按照项目实际接口和网关实现调整：
external-form:
enabled: true
token-expire-minutes: 30
max-submit-per-token: 1
rate-limit:
requests: 20
window-seconds: 60
audit-log: true
配合接口调用时，建议把一次性 Token、业务幂等键和来源信息一起纳入服务端校验：
curl -X POST "https://example.com/api/external/forms/customer-intake" \
-H "Content-Type: application/json" \
-H "X-Form-Token: replace-with-short-lived-token" \
-H "Idempotency-Key: customer-20250308-001" \
-d '{
"name": "张三",
"company": "示例科技",
"phone": "13800000000"
}'
不要只在前端隐藏表单字段。服务端仍应重新校验字段白名单、枚举值、文件类型、租户归属和提交次数。
代码生成器：模板决定交付效率
代码生成器的价值不只是少写几个实体类，而是让团队可以把已有工程规范固化到模板中。V3.9.5 对生成器模板进行增强后，可以更好地覆盖分层结构、接口代码、前端页面和常用业务配置。
实践中可以把模板维护分成三层：
- 基础层：实体、Mapper、Service、Controller 等通用文件。
- 业务层：租户字段、组织权限、审计字段、逻辑删除和数据字典。
- 项目层：团队自己的异常处理、接口响应格式、前端组件和测试骨架。
这样做的好处是，生成器产出的代码更接近可提交状态，而不是生成后还要进行大规模手工重构。代价是模板需要纳入版本管理，并通过示例表和回归检查持续验证。特别是 Spring Boot 4 架构升级后，旧模板中的依赖、配置方式和接口约定都应该重新检查。
一个简单的模板验收清单可以包括：
- 新生成项目能否通过编译和基础测试。
- 生成的 API 是否遵循统一响应和异常规范。
- 多租户、权限和审计字段是否按项目要求生成。
- 前端页面在新增、编辑、查询和导出场景下是否完整。
- 模板升级后，历史业务代码是否仍能增量生成。
AI 应用与 AI Flow：从模型接入走向可运营流程
这次升级的 AI 部分覆盖面较广，重点包括模型接入、知识库、流程编排、分享 Token 和访问限流。
模型接入能力决定了应用能否适配不同供应商和不同部署方式。工程上不应把模型名称、密钥和供应商参数散落在业务代码中，而应统一配置并通过环境变量或密钥管理系统注入。知识库则解决了模型回答企业内部资料的问题，但资料切分、权限过滤、版本更新和引用追踪仍然需要业务团队负责。
AI Flow 的意义在于把一次对话扩展为可组合流程。例如，一个流程可以先识别用户意图，再查询知识库，随后调用业务接口，最后由模型整理结果。流程越复杂，越需要记录每个节点的输入、输出、耗时和失败原因。
分享 Token 和访问限流尤其适合公开体验、内部协作和嵌入式应用场景。建议将分享链接视为受控凭证，而不是永久公开地址。可以按以下思路设置策略：
ai-flow:
share-token:
ttl: 2h
single-use: false
require-tenant-check: true
access-limit:
per-token: 60/minute
per-ip: 120/minute
observability:
record-node-duration: true
mask-sensitive-input: true
这些键名是可改造的配置示例，并不代表所有项目的固定配置格式。真正上线前，还要验证 Token 吊销、过期后的行为、限流返回码、代理层真实 IP 识别，以及模型调用失败时的降级路径。
安全、集成与可观测性补齐生产拼图
AI 能力越开放，安全边界越需要明确。访问限流可以降低滥用和突发流量风险，分享 Token 可以控制访问入口，OpenAPI 日志则帮助团队追踪调用来源、响应状态和异常位置。三者结合后，系统才更接近可运营状态。
OpenAPI 日志建议至少记录以下信息：
- 请求时间、接口路径和请求方法。
- 租户、用户或调用方标识。
- 响应状态、耗时和错误码。
- 关联业务 ID 或幂等键。
- 脱敏后的请求摘要和响应摘要。
密码、访问令牌、模型密钥、身份证号和完整用户输入不应直接写入普通日志。AI 场景尤其要注意 Prompt 和知识库内容可能包含内部信息，日志脱敏不能只依赖关键词替换。
新增飞书集成后，企业可以把 JeecgBoot 中的业务通知、流程或数据能力连接到协作平台。接入时要单独管理应用凭证、回调签名和事件重放问题，并为第三方接口设置超时、重试上限和失败告警。不要让外部平台的短暂故障阻塞核心事务提交。
升级时建议按业务链路验证
V3.9.5 涉及架构、低代码、AI 和集成模块，适合分阶段升级和验证：
- 先在测试环境确认 Spring Boot 4 相关依赖、配置和自定义扩展能够正常启动。
- 使用真实表结构验证多数据源、外部填报和代码生成结果。
- 对 AI Flow 执行成功、超时、模型不可用、知识库无结果和节点异常测试。
- 验证分享 Token 的签发、过期、吊销、租户隔离和限流行为。
- 检查 OpenAPI 日志是否脱敏，并确认日志量不会拖慢高频接口。
- 对飞书回调、重复事件、接口超时和凭证轮换建立运维流程。
这次版本升级的判断标准，不应只是“服务能启动”。更重要的是：生成的代码是否符合团队规范，外部表单是否能被安全地开放，AI 流程是否可追踪可限流，第三方集成是否具备失败恢复能力。对于已有 JeecgBoot 项目，建议先盘点自定义模板、数据源配置、AI 扩展和网关规则，再选择影响最小的业务模块进行灰度验证。