💥 从零构建脚手架：Zeka.Stack 设计理念、解决痛点与亮点特性
💥 从零构建脚手架：Zeka.Stack 设计理念、解决痛点与亮点特性
dong4j
🧠 初心：为什么要从零开发脚手架？
在众多脚手架如 RuoYi、yudao 等百花齐放的当下，从零造个轮子听起来似乎有些“何苦为难自己”。但现实却是，用别人的轮子，不一定跑得更快。
当你频繁地遇到这些问题：
- 脚手架升级一动就“爆炸”，依赖冲突层出不穷；
- 每次新建项目都得 copy/paste 三五个模块，配置头都大；
- 项目结构越来越重，协作越来越难；
- 插件脚手架不好用，代码生成一团糟；
你就会明白：一个真正贴合团队/企业开发场景的脚手架，是生产力的倍增器，而不是负担的制造者。
这，就是 Zeka.Stack 诞生的背景。
💥 我们要解决哪些“开发痛点”？
Zeka.Stack 不是为了炫技，而是为了解决我们真实踩过的坑。以下是我们希望彻底优化的问题：
1. 项目依赖管理地狱
- 多模块工程中依赖版本冲突频发，项目启动失败；
- 依赖升级时担心牵一发而动全身。
💡Zeka.Stack 的解决方案：
- 统一公司级 BOM 管理，所有项目继承同一套依赖版本；
- 通过多级父模块划分业务、技术、部署职责，升级只改一行版本号。
2. 重复配置太多，效率低下
- 新项目初始化要配置一大堆 Plugin、Checkstyle、Deploy Script；
- Spring Boot 自动配置项繁杂，易漏、易错。
💡Zeka.Stack 的解决方案：
- 全面自动化：Maven 插件 + Annotation Processor 一起上；
- IDEA 插件生成配置文件、脚本、依赖，无需手动；
3. 项目结构不清晰，模块间耦合度高
- 模块间循环依赖，业务逻辑耦合难拆；
- 项目随时间变“胖”，维护成本飙升。
💡Zeka.Stack 的解决方案：
- 完整分层架构，完全隔离基础层、业务层、产品层；
- 明确模块边界，职责单一、依赖可控。
⚙️ Zeka.Stack 的核心特性
Zeka.Stack 不仅是个脚手架，它是一套开发体系，一整套从零到一的“落地工程化方案”：
✅ 企业级依赖管理
- 三层 BOM：依赖版本、插件版本、构建配置分离；
- Maven Enforcer 插件保障依赖无冲突。
✅ 开箱即用的技术组件
- 日志、缓存、认证、任务调度、接口文档…一行依赖全搞定；
- Spring Boot Starter 化封装，全模块可插拔。
✅ 插件化开发体验
- IDEA 插件支持 hosts 管理、配置解密、MyBatis 快速跳转；
- Maven 插件自动生成部署脚本、Checkstyle 校验、CI/CD 集成。
✅ 自动生成与统一规范
- 注解 + Processor 自动生成 spring.factories 等 SPI 文件；
- 一致性开发规范，强制代码格式，减少 Merge Conflicts。
✅ 低侵入、易升级
- 支持 ThinJar 打包，Jar 可替换、配置可热更新；
- 升级组件只需改版本号，开发零改动。
🧩 和别的脚手架相比，有什么不一样？
| 特性 | 其他开源脚手架 | Zeka.Stack |
|---|---|---|
| 项目依赖管理 | 通常是项目独立管理 | 公司级统一 BOM，依赖不出错 |
| 插件支持 | 少，或难以定制 | IDEA + Maven 插件强力集成 |
| 可维护性 | 高耦合，升级难 | 分层分模块，升级只改版本号 |
| 文档 & 示例 | 不全或缺乏中文 | 全组件样例，文档齐全 |
| 架构升级路线 | 靠个人维护或停更 | 内部持续演进，有版本规划 |
🔮 未来计划：从 JDK8 到 JDK21 的升级之路
虽然目前很多企业仍停留在 JDK8，但我们不打算止步于此。Zeka.Stack 将采用 渐进式 Java 升级策略：
- 当前阶段（JDK8）：确保兼容主流企业运行环境，支持老旧系统、最大化适配范围；
- 过渡阶段（JDK17）：引入现代语法与更高性能，适配 Spring AI 等新技术栈；
- 目标阶段（JDK21）：走向 Java LTS 的未来标准，引入虚拟线程、Record 模型等新特性，拥抱云原生与 AI 的融合。
这种策略既保障企业的稳定运行，也预留了技术演进的空间，让脚手架始终保持活力。
🧑💻 Zeka.Stack 是为谁而造？
这个脚手架并不是万能钥匙，而是为“落地型开发者”而生：
- 对于企业开发者：你需要一套规范的、可控的脚手架，来统一协作开发，减少技术债；
- 对于架构师与中高级程序员：你需要高度可定制、可扩展的组件体系；
- 对于开源爱好者与独立开发者：你需要一套即开即用的方案，不想“踩坑三年重造轮子”。
🤔 Zeka.Stack 只是一个基础脚手架
我从未将 Zeka.Stack 称为一个“框架”，因为在我看来，只有像 Spring、Play Framework、Micronaut 这类具备更高抽象能力、运行机制设计、强扩展性和通用性的项目，才能真正称为框架。它们关注的是如何构建通用的开发模式和运行时行为，具有明确的技术范式，并与具体业务逻辑保持解耦。
而 Zeka.Stack 则是在 Spring 等框架之上，封装企业内部通用的工程结构、编码规范与业务基础能力，更偏向于一种工程化工具或项目模板。它通过预设模板、配置与规范，帮助团队快速搭建项目骨架，生成重复性代码，专注提升业务系统的开发效率与可维护性。
基础脚手架概括如下：
特性：
- 通常包含“基础框架 + 项目结构 + 通用组件 + 模板代码”。
- 封装企业级的通用能力，如用户认证、统一异常、权限模型、多租户等。
- 更贴近实际业务，强调开箱即用与统一开发体验。
作用：
- 快速启动新项目，减少重复劳动。
- 推动团队最佳实践的标准化落地（如统一日志、安全规范、接口风格等）。
- 提升项目之间的一致性，降低维护和接手成本。
事实上，过度的灵活性并不总是好事。在企业级业务开发中，我们更关注的是代码结构的一致性与系统的长期可维护性。
Zeka.Stack 通过适度的约束（如目录结构、模块划分、命名规范、代码模板等），在一定程度上抑制了“过度个性化”的开发习惯，为团队提供统一的开发语言与协作基线。这样，当项目需要交接、协作或演进时，团队成员无需面对风格各异、结构割裂的代码库，极大降低了理解和维护成本。
👉 接下来会写什么？
这是 Zeka.Stack 系列的第一篇，Zeka.Stack 也在持续迭代与完善, 我会将开发过程整理出一系列文章持续输出, 比如:
- 如何初始化一个基于 Zeka.Stack 的项目？
- 各个模块如何解耦、组合与拓展？
- 实战：一键部署 + 自动生成配置 + 脚手架构建体验
📌 下一篇预告：《用 Zeka Stack 打造可维护、高效开发的工程骨架》
🙋♂️ 常见问题解答（FAQ）
Q1：Zeka.Stack 是否开源？
暂未开源，但将来会择机发布部分组件。
Q2：Zeka.Stack 可以用于哪些场景？
主要适用于企业级微服务项目、快速构建中后台系统、标准化脚手架系统、SaaS 系统搭建等。
Q3：它能兼容 Spring Boot 官方更新吗？
可以，目前基于 Spring Boot 2.x，未来将支持 3.x 并提供迁移指导文档。
📚 延伸阅读 & 推荐资源
如果你读到这里，相信你已经明白了我们为什么执意从零开始，为什么在各种轮子横飞的今天，依旧选择自己打磨每一个细节。Zeka.Stack 是一套从业务中生长出来的系统，不是为炫技，而是为实战。
📢 如果你感兴趣，欢迎留言讨论、建议或关注系列更新。别忘了分享给同样为技术苦恼的朋友们吧！
