38 归档分页
370 留言互动
4 核心专题

从依赖扫描到可信发布:Java 项目软件供应链安全实战

传统 Java 项目往往只关注依赖漏洞,却忽略了依赖解析、CI 构建、制品存储和部署替换等供应链风险。本文从工程实践出发,讲解如何使用 CycloneDX Maven Plugin 生成 SBOM,利用 Trivy 扫描漏洞与许可证,通过 Cosign 为镜像签名并绑定 SBOM Attestation,再结合 SLSA Provenance、VEX 和策略门禁建立可验证的发布链路。同时分析 SBOM 与最终镜像差异、签名密钥隔离、例外审批、历史清单归档和持续重扫等生产落地问题,帮助 Java 团队将发布流程从“默认信任”升级为“基于证据验证”。

抖音续火花助手:支持定时发送、网页管理和登录态更新

抖音续火花助手是一款面向个人用户的开源自动化工具,可部署在自己的服务器上,每天定时向指定好友发送续火花消息。项目提供可视化网页后台,支持好友与消息管理、登录态上传、联系人同步、干跑测试、立即发送、任务停止、结果记录和日志查询。同时具备会话校验、搜索兜底、发送确认、限流识别、超时终止和浏览器回收等保护机制。项目基于FastAPI、Playwright和Vue开发,支持Python及Docker部署,并提供Windows登录态更新工具,适合个人低频自用和自动化技术学习。

GitHub可用性改造背后的故障隔离真相

本文指出,系统出现性能问题或故障后,团队常倾向于拆微服务、上 Kubernetes、增加机器,但这些手段不会自动带来高可用。GitHub 2026 年可用性改造的真正主线不是增加服务数量,而是持续移除共享故障点,把故障限制在更小范围。微服务数量不等于故障隔离,真正隔离包含代码边界、资源边界和故障边界。GitHub 通过迁出认证权限、让仓库与 Pull Request 使用独立基础设施、降低单机房依赖,逐步建立隔离。文章提出可靠性改造五原则:识别核心用户路径、优先隔离资源、主动丢弃负载、逐步放量快速回退、高可用不等于所有功能正常。中小团队可先画依赖关系、识别共享资源、建立软隔离,再拆分高风险域。真正架构升级是控制故障传播,拆服务前应问:模块失控后,能否只让自己失败?

别只加索引了:PostgreSQL 18底层性能变革解读

PostgreSQL 18 的性能优化不再局限于加索引或调 SQL,而是从底层重构数据访问与建模方式。其异步 I/O 子系统通过 worker 或 io_uring 并发读取,显著改善大表扫描、Bitmap Heap Scan 和 VACUUM 的吞吐;B-Tree Skip Scan 允许联合索引在缺失最左列时仍能部分利用;原生 UUIDv7 提供时间有序标识,提升索引写入局部性;虚拟生成列将确定性行内计算统一到数据库;增强的 RETURNING OLD/NEW 可一次获取修改前后数据。文章强调,这些能力并非自动加速所有查询,升级前应基于真实负载测试,合理配置 I/O 并发参数,并关注统计信息恢复与生态兼容。

成年以后才明白:生活没有彼岸,只有一程又一程

小时候我们总以为人生存在一个“彼岸”:毕业就好了、找到工作就好了、工资高了就好了、买房结婚以后就好了。真正长大才发现,生活并不会在某个节点之后突然变得无忧无虑。工作、收入、家庭、健康,每个阶段都有属于自己的问题。成熟也许不是彻底摆脱焦虑,而是接受人生的不确定性,改变能够改变的,接受暂时无法改变的,同时不再把幸福无限推迟到未来。人生没有永久的彼岸,我们真正需要学习的,是在一次次渡河的过程中,仍然认真吃饭、认真生活、珍惜身边的人,也珍惜那些平凡却真实的幸福瞬间。

MCP协议大改之后:Java与Spring AI如何跨越兼容性断层

MCP 2026-07-28规范移除了初始化握手和协议级Session,转向每次请求自带版本与能力声明的无状态模型。当前Java MCP SDK 2.0.0和Spring AI仍基于2025-11-25协议,接入客户端时可能出现探测失败、未知方法返回500等问题。本文梳理新旧协议差异与Java生态现状,并给出兼容测试、状态外置、权限校验、协议网关和双栈灰度方案,帮助Java团队平稳完成MCP升级。

AI接口能跑不等于可靠:如何建立回归评测与质量门禁

大模型接口返回 HTTP 200,并不代表回答正确。Prompt、模型、RAG、工具和参数的任何变化,都可能引发难以察觉的质量回归。本文基于 Java、JUnit 与 Spring AI 2.0,设计一套可落地的 AI 回归测试体系:使用版本化数据集管理正常、边界、对抗和历史失败样本,通过确定性规则拦截格式、安全、Token 与时延问题,再使用模型裁判评估正确性、事实一致性和相关性,并结合多次运行通过率、基线对比和 CI 质量门禁,让 AI 功能从人工聊天验收走向可量化、可回归、可持续交付。

从ThreadLocal到ScopedValue:Java上下文传播正在改变

随着 Java 应用从传统 CRUD 走向 AI Agent,userId、tenantId、traceId、conversationId 等上下文需要在更复杂的调用链与并发任务中稳定传播。JDK 25 正式定稿的 ScopedValue,为“上游绑定、下游只读、任务结束自动失效”的场景提供了比 ThreadLocal 更清晰的语义。本文结合虚拟线程、结构化并发与 Spring AI ToolContext,分析 ScopedValue 的设计原理、适用边界、异步传播限制及安全注意事项,并给出 Spring Boot 项目的上下文分层与迁移思路,帮助开发者重新理解 Agent 时代的 Java Context 设计。

从96%到70%

本文记录了把四个独立的 Spring Boot 项目(chat、puke、zepp、blog)合并为一个 Maven 多模块工程,只启动一个 total‑app.jar 的实践。原先每个项目占用一个 JVM,导致服务器内存接近 96%;通过在根 pom 统一依赖、在 launcher 中用 SpringApplicationBuilder 依次启动四个 ApplicationContext,并将配置分别放在 chat.yml、puke.yml、zepp.yml、blog.yml 中,消除了 JVM 底座的重复开销,内存降至约 70%。文章重点阐述了类路径冲突、资源目录重名、自动配置串扰和日志全局化等踩坑及对应的统一依赖、资源隔离、spring.autoconfigure.exclude 等解决方案。部署时仅需一次打包并用单条 java 命令启动,端口和 Nginx 配置保持不变,运维更简洁。该方案适合资源受限、访问量不高且对隔离要求不强的场景,虽牺牲了故障隔离,但能显著降低内存压力,为小型服务器提供务实的优化路径。