🧱 后端开发与架构
未读这个框架，到底哪里不对劲去年下半年我开始接手一个研发底座的优化工作。什么叫研发底座？说白了就是公司内部那套脚手架和通用组件——鉴权、日志、异常处理、缓存、加解密，这些每个项目都要用的东西，抽象出来形成框架，避免每个团队重复造轮子。 这套底座已经迭代了两年多，支撑着十几个微服务的正常运行。按理说，经过这么长时间的打磨，应该比较成熟了。但当我真正开始读代码的时候，总感觉哪里不太对。不是说它不能用，能用，而且一直在用。而是说，如果你让我从零开始设计一个同样功能的东西，我不会这样做。 这其实是一个挺微妙的位置。作为后来者，你不能一上来就指指点点说这个不行那个要改——每个设计决策背后都有当时的上下文，也许那时候只有两个人，业务急着上线，架构师做了一个在当时最合理的取舍。但问题是，当时的上下文现在可能已经不存在了。团队从三五个人变成了几十个人，服务从两三个膨胀到了十几个，当初那个”先这么写着，后面再说”的设计选择，现在已经变成了后来者的认知负担。 打个比方。我在看网关路由配置的时候，发现一个现象：每个微服务都定义了自己的 context-path： 12345# user-serviceserv ...
📋 背景与挑战业务背景IntelliAI Engine 是一个开源项目，作为 IntelliJ IDEA 插件的统一 AI 服务抽象层，需要对接各种 AI 服务提供商。在实际业务场景中，我们遇到了一个特殊的挑战： 公司内部使用的星辰大模型接入需求： 安全管控约束： 公司内部的星辰大模型无法在外部环境使用 由于插件是开源项目，出于安全管控的原因，不能将内部对接逻辑直接暴露到开源代码中 内部模型的认证、连接等敏感信息必须与开源项目隔离 已有工具项目： 公司内部已经在前端时间通过 Java 实现了一个对接内部星辰大模型的工具类项目 该项目已经完成了 WebSocket 连接、OAuth2 认证、会话管理等核心功能 项目已经能够稳定运行，并通过 Swing 界面为用户提供服务 业务推广需求： 此次因为公司内部推广，需要将星辰大模型接入到现有的 Engine 插件中 需要让公司内部用户能够通过 IntelliJ IDEA 插件使用星辰大模型 架构设计考量： 复用性：希望直接复用已有的工具项目，避免重复开发 安全性：保持开源项目与内部项目的职责分离，确保敏感代码不泄 ...
前言在开发 Markdown Image Kit 插件时，遇到了一个棘手的问题：在 Markdown 文件中粘贴图片时，自定义的粘贴处理逻辑完全不被触发，直接走了 IDEA 默认或Markdown 插件的处理逻辑。经过深入排查，发现问题的根源在于 IntelliJ IDEA 的粘贴处理机制优先级问题。 本文将详细记录问题的排查过程、根本原因分析以及最终的解决方案。 问题背景Markdown Image Kit 是一个 IntelliJ IDEA 插件，主要功能是在 Markdown 文件中粘贴图片时，自动将图片上传到图床或保存到指定路径，并插入相应的Markdown 图片标签。 插件通过拦截 EditorPaste 动作来实现自定义粘贴逻辑： 123<editorActionHandler action="EditorPaste" implementationClass="info.dong4j.idea.plugin.action.paste.PasteImageAction" ...
🎉 高能分享
未读那个让我后怕的早晨12 月 10 号，我还在发朋友圈说因为 Next.js(准确的说应该是 React) 的漏洞需要升级 Dify, 不过因为时间的原因只是将几个受影响的 Next 服务下架, 并没有进行升级。 今天有点时间打算全部升级一下, 结果才发现——我其实在 12 月 5 号就已经被攻击了。 这是我第一次因为第三方服务的漏洞遭遇真实攻击。虽然最终没有造成更严重的后果，但从”被动挨打”到”定位证据、完成处置”，整个过程给了我巨大的冲击。那种感觉，就像你早上醒来发现家里被翻了个遍，但你还不知道丢了什么。 所以，我决定把这次被攻击的全过程记录下来——一方面梳理教训、为后续安全防控留出可复盘的参考，另一方面也提醒其他 Next.js 用户这次事故的严重性，尽快完成升级。 相关漏洞信息： Next.js 官方公告 Critical Security Vulnerability in React Server Components Denial of Service and Source Code Exposure in React Server Components CV ...
简介本文是 Spring AI 入门教程的第一部分，将带你从零开始搭建一个 Spring AI 应用，集成 OpenAI（通义千问兼容模式）和 Anthropic（Claude）两个聊天模型，并解决实际开发中可能遇到的各种问题。 参考文档：Your First Spring AI 1.0 Application 刚刚新开了一个 Spring AI 的 教程项目, 欢迎大家 star 和 fork！ 准备工作在上一篇 在 Docker 中部署 PostgresML 实现数据库内机器学习 中，已经成功在 PostgresML 中创建了数据库，并成功进行了 PostgresML 的相关测试。现在我们将以 PostgresML 为底层数据库，基于 Spring AI 来完成一个示例项目，学习 Spring AI 的相关概念以及 API 的使用。 项目初始化打开 Spring Initializr，在你的项目里添加以下依赖： PgVector (PostgreSQL 的向量扩展) GraalVM Native Support (GraalVM 原生镜像支持) Actuator (应 ...
🤖 AI:人工智障
未读背景随着人工智能技术的快速发展，Java 开发者也在积极探索如何将 AI 能力集成到企业级应用中。Spring 团队发布的 Spring AI 项目为 Java 生态带来了强大的 AI 集成能力。特别是 Spring AI 1.1.0 版本的正式发布，使得使用 Java 开发 AI 应用变得更加便捷。 在 AI 应用开发中，向量数据库扮演着重要角色，特别是在处理文本嵌入和语义搜索场景下。PostgresML 作为一个强大的 PostgreSQL 扩展，能够直接在数据库内部实现机器学习功能，为 AI 应用提供了高效的向量存储和检索能力。 本文将详细介绍如何在 Docker 环境中部署和配置 PostgresML，为后续的 AI 应用开发打下坚实基础。 简介PostgresML 是一个强大的 PostgreSQL 扩展，它将机器学习功能直接集成到数据库内部。通过 pgml 扩展，开发者可以在数据库层面实现文本嵌入、语义搜索等 AI 功能，无需额外的外部服务依赖。 在 Docker 容器中部署 PostgresML 具有以下优势： 环境一致性：确保开发、测试和生产环境的一致性 快 ...
🏠 HomeLab:中年男人之友
未读前言在群晖上整点”高级”的网络配置 —— 比如加个反向代理、换个监听端口、写条 URL Rewrite —— 我第一反应都是： 直接去改 /etc/nginx/nginx.conf 不就好了？ 然后就被坑了。具体坑法是：配置当场生效，重启一次就没了。 我当时还以为是自己改错了文件权限或者 reload 命令不对，反复核对了好几次，最后才反应过来 —— 群晖的 Nginx 配置根本不是一个”手写”的文件，而是开机时用模板生成出来的。你改得再仔细，系统一重启就用模板重新写一份，你的改动被原样冲掉。 这篇把整个机制说清楚，再给一个我自己一直在用的”不碰模板、不丢配置“的做法。 群晖 Nginx 的配置是怎么来的先 SSH 上群晖看一眼： 12sudo -ils /usr/syno/share/nginx/ 能看到一堆 .mustache 文件： 1234WWWService.mustacheWWW_Main.mustacheDSM.mustache... （还有十几个） 这就是群晖 Nginx 配置的”源头”。DSM 每次启动（或者你在 WebStation、控制面板里动配置 ...
🙉 Zeka.Stack
未读🧑💻 简介作为一个 Java 后端工程师，我相信你一定遇到过下面这些问题： 使用 IDEA 启动一个 Spring Boot 项目，第一行就出现红色告警：发现多个 slf4j 实现类，提示你要排除一个； 本地开发一切正常，一部署到测试环境却报错：找不到某个 class； 项目中的 pom.xml 有上百个依赖，不知道哪个服务哪个功能，谁也不敢轻易动； 多模块之间彼此依赖，模块 A 引用模块 B，模块 B 又反过来依赖模块 A，形成“依赖闭环”； …… 经历过大大小小的 Spring Boot 项目后我发现，不论是大厂还是小团队，很多项目对 Maven 的依赖管理都重视不足。 重复引入、版本冲突、依赖混乱、模块耦合这些问题，几乎是通病。 好一点的团队会搭建一个公司级的 parent 项目来统一依赖版本；大多数直接沿用 spring-boot-starter-parent；更差的，哪缺啥引啥，能跑就行，构建配置几乎没人管。 为什么要重新思考 Maven 项目的组织结构? 因为当项目开始变大：%% %% 依赖管理就成了地雷阵，一改就炸； 多人协作时，版本不一致、依赖冲突 ...
🙉 Zeka.Stack
未读📖 简介在上一篇 🧪 Maven Profiles 的使用场景案例分享 我们通过 Profiles 的实际案例大致了解了它的使用方式, 并详细梳理了 Profiles 的优先级, 不过也挖了一个坑: 为啥我要将 settings.xml 和项目代码放在一起? 比如 arco-supreme 项目的代码结构为: 12345678910111213141516$ tree -a -I '.git|.idea'.├── .editorconfig├── .gitignore├── .mvn│ ├── jvm.config│ ├── maven.config│ ├── settings.xml│ └── wrapper│ ├── maven-wrapper.properties│ └── MavenWrapperDownloader.java├── LICENSE├── mvnw├── mvnw.cmd├── pom.xml└── README.md 可以看到 settings.xml 文件放在了 .mvn 目录下, 且 ...
🙉 Zeka.Stack
未读📖 简介在上一篇 🚀 从注册到发布：Maven 中央仓库上传 jar 实践 中，我们成功将本地 jar 包上传到了 Maven 公共仓库。 那篇文章的配置比较基础，主要目的是跑通流程。而在实际开发中，为了更好地适配不同环境，还需要做一些必要的优化配置。就像写代码一样，第一步是跑通，再逐步打磨细节，这次我们就来看看如何通过 Maven Profiles 实现多环境切换。 所以这篇文档我将介绍 Maven 的 Profiles 配置, 目标是让 Zeka.Stack 相关的组件既能上传到 Maven 公共仓库, 也能让大家在进行二次开发后, 只上传到公司 Maven 私服. 当然这仅仅是 Maven 的 Profiles 的一个实际应用场景, 其他还比如 根据不同 Profile 引入或排除某些依赖; 针对多模块项目，通过 Profiles 控制是否构建某些子模块; 结合 resources 标签中的 <filtering>true</filtering>，实现配置文件模板化等等场景. 🔀 deploy 环境切换直接上配置: 1234567891011 ...
🙉 Zeka.Stack
未读✨ 前言虽然 Zeka.Stack 是全开源的, 但是每个组件也可以单独使用, 为了避免需要克隆所有项目然后本地 install 才能使用, 所以最简单的方式就是将 Zeka.Stack 的组件上传到 Maven 公共仓库, 所有就有这篇水文. 为什么说是水文呢, 因为这类的文章网上也有很多了, 这里再写一遍其实没有啥价值, 不过为了完善我 Zeka.Stack 的知识体系, 所以还是决定写一写. 🧰 准备工作这里演示使用自己的域名来作为 groupId, 所以需要 DNS 验证, 其他方式比如 GItHub, GitLab 等验证相对来说更容易些. 个人觉得 GitHub 作为 groupId 太长了, 比如我如果使用 GitHub 验证的话 groupId 就是 io.github.dong4j, 而且为了打造自己的 IP, 所以选择使用一个二级域名, 正好前段时间在 Cloudflare 注册了 dong4j.dev 的域名, 这里就可以用上了. 如果要图方便的话, 可以直接使用 arco-supreme 这个项目来做测试. 📝 注册 Sonatype 账户自 20 ...
🙉 Zeka.Stack
未读🧑💻 简介在日常开发中，写业务不难，难的是「工程一上来就乱」、「依赖一多就扯皮」、「构建一复杂就抓狂」。Zeka Stack 希望通过系统化的工程体系来解决上述问题. 它不是啥“重框架”，也不是为了造新轮子，而是一个工程提质提速的脚手架体系，用清晰的模块划分、统一的构建规范和灵活的生态扩展，让你在开写业务代码之前，项目骨架就已经整整齐齐、顺手好用。 一句话：让你团队少踩坑、构建不抓狂、协作有章法。 🧱 用 Zeka Stack 打造可维护的工程骨架大家肯定遇到过这样的问题: 某次新项目启动，一开始小组成员各自拉模块、加依赖、写配置，几天后就发现： 依赖重复、冲突，启动报错； 构建流程不一致，有人能打包，有人不能； 模块命名五花八门，新人根本无从下手; 尤其是多个团队协同开发微服务系统时，经常遇到的问题包括： 痛点 描述 项目结构混乱 每个团队按自己的理解组织模块，结果变成“大杂烩” 构建方式不统一 有人用 mvn，有人用 idea，有人手动打包，构建经常失败 重复造轮子 各业务组开发重复功能，没有统一组件库 依赖冲突频发 多模块之间版本不一 ...
🙉 Zeka.Stack
未读🧠 初心：为什么要从零开发脚手架？在众多脚手架如 RuoYi、yudao 等百花齐放的当下，从零造个轮子听起来似乎有些“何苦为难自己”。但现实却是，用别人的轮子，不一定跑得更快。 当你频繁地遇到这些问题： 脚手架升级一动就“爆炸”，依赖冲突层出不穷； 每次新建项目都得 copy/paste 三五个模块，配置头都大； 项目结构越来越重，协作越来越难； 插件脚手架不好用，代码生成一团糟； 你就会明白：一个真正贴合团队/企业开发场景的脚手架，是生产力的倍增器，而不是负担的制造者。 这，就是 Zeka.Stack 诞生的背景。 💥 我们要解决哪些“开发痛点”？Zeka.Stack 不是为了炫技，而是为了解决我们真实踩过的坑。以下是我们希望彻底优化的问题： 1. 项目依赖管理地狱 多模块工程中依赖版本冲突频发，项目启动失败； 依赖升级时担心牵一发而动全身。 💡Zeka.Stack 的解决方案： 统一公司级 BOM 管理，所有项目继承同一套依赖版本； 通过多级父模块划分业务、技术、部署职责，升级只改一行版本号。 2. 重复配置太多，效率低下 新项目初始 ...
这段时间，很多老开发者都在经历同一种拧巴。 写了十几年代码，按理说经验越多，人应该越稳。现实却常常相反，反而更容易迷茫。一方面 AI 把开发门槛拉低了，很多以前要靠经验吃饭的活，现在几小时就能拼出来。另一方面，国内互联网环境这两年确实不太乐观，岗位少了，强度还高。你会突然意识到：只靠“能写代码”，安全感是不够的。 先别急着找“完美答案”，先把节奏稳住。更现实的策略是：先找一份相对稳定、强度别太离谱的工作，保证现金流和生活秩序；同时把 macOS 小工具当成长期副业去做，先做几个小产品试水。 为什么会卡住回头看，很多技术人副业做不起来，问题不一定出在执行力，更多是认知还停在工程师模式里。太容易把“会什么技术”当成价值本身，但市场并不这么看。市场只看结果。 这句话听起来老生常谈，但越到中后期越痛：技术优势，不等于商业优势。 代码、架构、算法当然重要，但那是生产过程。用户掏钱买的，是他的问题被解决之后的结果。 三个转变，还是那三个转变这三个转变放到现在依然成立，而且体感更强。 1）沟通：别把工具箱倒给对方看以前聊方案，也会下意识说一堆技术词：微服务、Docker、消息队列、缓存分 ...
