- 博客(173)
- 收藏
- 关注
RSS订阅原创 用 AI 从零构建高并发防超卖 WMS 系统（五）：AI 审 AI——Codex 红军审查帮我找到 5 个致命超卖漏洞
文章摘要 本文介绍了利用AI进行代码审查的实践，通过让Claude Code（蓝军）编写代码，Codex（红军）进行审查，形成AI互查机制。相比人工审查，AI审查具有覆盖面广、直言不讳、耐心持久等优势。作者分享了8轮审查历程，重点剖析了5个致命漏洞的发现与修复过程，包括Lua超时导致的超加、对账系统引发的空卖、TOCTOU问题导致的双扣、心跳异常产生的孤儿扣减，以及强制修改引发的撤销问题。文章还详细介绍了AI审查流程，并总结了核心教训：对账系统本身可能制造不一致，修复工具设计不严谨比不修更危险。这种AI互查
2026-07-15 09:45:18
454
原创 用 AI 从零构建高并发防超卖 WMS 系统（四）：对账 Job + TTL 释放 + 幂等清理，最终一致的最后一道防线
本文介绍了构建高并发WMS系统时确保库存最终一致性的4个关键后台Job： 补偿重试Job：处理Redis扣减成功但DB落库失败的情况，通过定期重试和SETNX幂等机制确保数据一致，5次重试失败后转人工处理。 TTL超时释放Job：扫描过期预占记录自动释放库存，采用分页限流设计防止大量过期请求同时处理导致的系统雪崩。 对账Job：以流水表为基准核对Redis库存，采用"宁可少卖不可超卖"的保守策略：Redis库存多于流水时仅对静默商品执行校正，库存不足时只告警不自动补充。 幂等清理Job：清理因进程崩溃导致的
2026-07-15 09:44:00
190
原创 用 AI 从零构建高并发防超卖 WMS 系统（三）：放弃数据库行锁！Redisson + Lua + CAS 怎么做到 200 并发 0 超卖
本文介绍了如何用 Redisson + Lua + CAS 实现高并发防超卖的 WMS 系统。传统方案使用数据库行锁（SELECT FOR UPDATE）导致性能瓶颈，200并发时系统卡死。新方案采用 Redis Lua 脚本实现原子扣减，结合异步落库和对账机制，实现200并发0超卖。核心优化点包括：将扣减操作移到Redis（10万+QPS），使用编程式事务仅包裹DB操作，通过最终一致性替代强一致性。文章详细拆解了8步完整链路，重点说明Lua脚本的两阶段检查机制确保原子性，并分析了DB操作失败时的补偿策略。
2026-07-15 09:43:13
142
原创 用 AI 从零构建高并发防超卖 WMS 系统（二）：19 个场景 + Lua 契约 + 状态机，设计阶段就堵死超卖
文章摘要：本文探讨如何在高并发WMS系统中从设计阶段预防超卖问题。作者通过AI穷举19个业务场景（正常流7个/逆向流6个/极端并发6个），采用状态机+Lua脚本+异常码三重保障机制。核心方案包括：1）预占状态机通过CAS乐观锁实现原子状态转换；2）Lua脚本实现All-or-Nothing两阶段库存扣减；3）对部分缺货场景采用整单失败策略保持一致性。设计亮点包含双层CAS防并发冲突、幂等键防重处理、同步释放Redis库存等，确保系统在200并发下仍能保持数据一致性。（149字）
2026-07-15 09:41:54
214
原创 用 AI 从零构建高并发防超卖 WMS 系统（一）：12 张点子卡片到 12 条架构铁律
本文介绍了如何利用AI辅助进行WMS仓储系统的架构设计。作者通过让Claude AI扮演"蓝军指挥官"角色，从四个维度（痛点放大、AI融合、灾难场景、反共识设计）进行头脑风暴，最终收敛出12条不可违背的架构铁律。文章重点展示了AI在架构设计中的三大优势：穷举所有场景、消除模糊地带、建立可执行规范。其中包含3个关键决策：选择最终一致性而非强一致性、优先采用AI旁路诊断而非核心决策、明确ES只做检索不承担库存真值。最终形成的12条铁律覆盖一致性、AI应用、编码规范等维度，为后续开发提供严格约束。这种方法避免了传
2026-07-15 09:41:07
172
原创 codex+cladue code在若依基础上实现高并发防超卖 WMS 系统
这篇文章介绍了一个使用AI辅助开发高并发防超卖仓储管理系统(WMS)的技术系列。作者作为4年经验的Java后端开发者，详细记录了从架构设计到上线的全过程。 核心亮点包括： 采用Redisson+Lua+CAS实现200并发0超卖 结合Spring AI和DeepSeek实现智能诊断 通过8轮AI代码审查发现5个致命漏洞 完整技术栈包含Spring Boot 3.4.7、Vue 3.5、Redis等 项目产出包含12条架构铁律、3个Lua脚本、40个单元测试等 该系列适合后端工程师、架构师及对AI辅助开发感兴
2026-07-15 09:40:16
187
原创 国投智能 Java 面试复盘：笔试题 + 技术面都问了什么？最后厦门 1.4w 通过
这篇文章记录了作者参加国投智能Java岗位笔试和面试的详细复盘。笔试主要考察Java基础、语法细节和编程题，包括标识符规则、i++与++i区别、try-catch-finally执行顺序、equals与==比较等基础知识点。面试则更侧重项目实践，涉及数据库优化、Spring AOP、微服务、Kafka、线程池等技术问题。 文章特色在于不仅列出题目，还提供了详细的解题思路和代码示例，如单例模式的双重检查锁机制、不使用split的字符串单词反转实现等。作者总结通过面试的关键在于：扎实的Java基础、能将原理与项
2026-06-10 09:45:49
500
原创 带引用来源的答案生成怎么设计？一次讲清回答模板、引用片段、拒答策略与可信输出
本文系统介绍了企业知识库问答系统中带引用来源的答案生成设计要点。作者指出可信回答需要包含结论、依据摘要、引用来源和不确定性说明四部分，强调拒答策略比错误回答更重要。文章提供了回答模板设计原则、常见陷阱及Java/SQL实现示例，提出企业级问答应追求"结构化、可追溯、有边界"的输出效果，而非单纯追求回答功能。最后总结企业知识库的理想输出应"更像一份带依据的回答"，而非普通聊天对话。
2026-06-10 09:44:48
224
原创 为什么很多知识库项目检索明明命中了，回答还是不准？
这篇文章系统讲解了知识库问答系统中重排和上下文组装的设计要点。作者指出召回阶段追求覆盖率往往会返回过多内容，而问答阶段需要精选最相关的少量上下文。文章分析了重排的四个核心功能：过滤、选择、排序和拼接，并提出了关键设计原则：TopK不宜过多、片段顺序要有依据、保留引用信息、去除冗余内容。通过Java和SQL代码示例展示了实现方法，并总结了面试回答技巧。最后强调效果提升的关键在于"重排更准、组装更好、上下文更干净"，而非盲目增加召回量。文章对优化知识库问答系统具有实用指导价值。
2026-06-10 09:44:16
196
原创 Java 面试高频题：企业知识库检索一般怎么做？
本文系统探讨了企业知识库权限控制的核心问题与解决方案。作者指出，知识库权限不同于普通后台权限，关键在于控制"模型能否获取知识"而非仅"页面可见性"。文章提出了三层权限控制方案：文档级权限、分段级权限和检索结果过滤，并强调权限必须前置到检索层而非仅后置处理。通过Java代码和SQL示例，展示了权限过滤的实现方式。文章还总结了常见设计误区和面试应答技巧，最后给出核心结论：企业知识库权限必须进入检索层，才能有效防止敏感信息泄露。
2026-06-10 09:43:42
203
原创 Java 面试高频题：embedding 和向量索引一般怎么做工程化？
本文系统介绍了知识库平台中向量化和索引链路的设计要点。作者指出向量化不只是调用API，而是需要将切块内容转化为"可检索、可过滤、可重建"的索引资产。关键设计包括：拆分chunk内容、向量生成、元数据补齐、索引写入、状态记录和重建能力六个环节；根据技术栈选择向量库（pgvector/ES/Milvus/Qdrant）；重视模型版本记录、元数据过滤、写入重试和重建能力。文中提供了Java和SQL示例，并总结了面试回答要点，强调设计应统筹考虑向量、元数据、版本、重试和重建等要素。
2026-06-10 09:42:49
211
原创 别只停在 Tool Calling 了，LangChain4j 的 MCP 接入这次讲透
本文介绍了如何在Java项目中通过MCP协议标准化接入外部工具和资源。MCP的核心价值在于统一不同系统的接入方式，避免为每个系统单独开发私有协议。文章提供了多种接入方式比较（stdio/HTTP等），并给出具体代码示例展示如何通过McpToolProvider将MCP工具集成到AI Service中。针对企业级应用，建议建立MCP连接注册中心进行统一管理，包括健康检查、工具命名映射和权限控制。文章还提供了企业级代码示例和SQL表设计，强调应分层处理连接管理、工具治理和业务集成，实现平台化闭环。
2026-06-04 20:09:30
217
原创 LangChain4j 实战：Golden Dataset、回放任务、评分表、发布门禁怎么做
LangChain4j测试与评测体系构建指南 本文针对AI项目特点，提出了一套完整的测试评测体系方案。核心内容包括： 问题分析：AI项目改动易导致质量silently下降，传统测试方法不足 解决方案：提出Golden Set、回放任务、评分维度和发布门禁四维体系 实施方法： 建立固定样本集覆盖各类场景 实现批量回放和版本对比 多维度评分（准确率、引用完整性等） 设置发布阈值门禁 技术实现：提供Java代码示例展示回放服务、评测器及SQL表设计 实践建议：强调样本代表性、结果存档和场景化阈值设置的重要性 该体
2026-06-04 20:08:41
203
原创 面试高频：输入审核、输出校验、重试重问在 LangChain4j 里怎么做
本文探讨了LangChain4j中Guardrails机制在AI应用安全与校验中的关键作用。文章首先指出真实场景下的输入输出风险，强调Guardrails能拦截违规输入、校验输出格式并支持自动重试/reprompt。通过对比表格区分Input/Output Guardrail的功能差异，结合客服机器人案例说明实际应用流程。文中提供了代码示例展示自定义Guardrails实现方式，包括JSON校验和业务规则验证，并建议企业采用GuardrailChain+人工审核的治理架构。最后提出监控指标建议，强调需区分错
2026-06-04 20:07:52
203
原创 LangChain4j 不是能跑就行，观测和指标这次讲具体
AI 调用真正上线以后，能不能看清楚每一次调用发生了什么，往往比回答本身更先决定你能不能把系统跑稳。如果你们项目已经接了大模型，你现在最想先看到的指标，是 token、耗时，还是工具调用明细？
2026-06-04 20:07:14
248
原创 LangChain4j 的聊天记忆别只放内存了，持久化这次讲具体
LangChain4j聊天记忆持久化方案 文章探讨了LangChain4j在多轮对话场景中的记忆持久化解决方案。主要内容包括： 核心问题：线上多实例、长会话环境下的上下文治理，包括会话记忆丢失、敏感信息留存等问题。 解决方案架构： ChatMemory管理模型可见内容 ChatMemoryStore负责存储位置 提供MessageWindow(按消息条数)和TokenWindow(按token数)两种窗口策略 企业级应用： 电商客服场景需要跨实例、跨天会话保持 提供完整闭环方案：从入口层到监控层的全流程设计
2026-06-04 20:03:24
351
原创 LangChain4j 实战：QueryRouter、重排、RetrievalAugmentor 怎么落地
摘要 本文探讨了LangChain4j在多知识源RAG系统中的路由与重排机制。当知识库扩展到多个来源时，简单的全量检索会导致噪音干扰和token浪费。文章介绍了两个核心组件：QueryRouter负责将查询路由到最相关的知识源，ReRankingContentAggregator则对检索结果进行重排优化。通过电商客服助手等实际案例，展示了如何先路由再重排的完整流程。文中还提供了代码示例，包括定义多个检索器、使用语言模型进行路由决策、以及构建完整的检索增强流程。最后强调企业级实现需要完整的可观测性和编排能力，
2026-05-28 16:17:42
335
原创 LangChain4j 实战：dynamicMaxResults、dynamicMinScore、dynamicFilter 怎么落地
本文探讨了LangChain4j中检索器(ContentRetriever)的关键优化策略，特别针对企业级RAG系统常见的召回范围过大、租户隔离和业务域收敛问题。文章指出单纯使用TopK召回往往不够，需要结合动态过滤、最小分数阈值和元数据过滤等多维度控制。通过具体代码示例展示了如何实现多租户知识库的动态检索，包括构建带动态参数的检索器、处理低分召回场景，以及企业级检索编排服务的实现方案。文章强调检索器应关注相关性和边界控制，而非简单向量搜索，并提供了从入口识别到质量评估的完整闭环落地建议。
2026-05-28 15:43:28
318
原创 LangChain4j 实战：动态工具、参数约束、幂等、人审链路怎么做
摘要： LangChain4j工具调用在企业应用中面临的核心挑战是边界控制问题。文章探讨了如何通过@Tool注解、动态工具和权限审计实现安全可控的工具调用。关键点包括：1)区分读写工具风险，分层治理；2)系统自动注入上下文参数；3)完整审计日志记录。文中提供了代码示例展示静态工具定义、角色动态下发工具、审计日志实现，以及企业级解决方案（ToolFacade+Policy+Approval组合）。特别强调高风险写操作必须通过人工确认链路，并给出了工具调用审计表的SQL设计。这些方法可确保AI在接入核心业务系统
2026-05-28 15:37:45
426
原创 LangChain4j 实战：文件加载、解析、切块、向量入库、同步日志一次讲透
本文深入探讨了LangChain4j在知识入库环节的关键技术与实践方法。文章首先指出许多RAG项目效果不稳定的根源在于知识入库流程的粗糙处理，强调需要建立完整的知识加工流水线。 核心内容包括： 知识入库的完整环节：文档加载（从多种来源读取）、文档解析（按格式选择合适Parser）、切块加工（控制chunk和overlap）、向量入库（使用EmbeddingStoreIngestor） 企业级应用场景：如企业知识库平台需要版本追踪、失败重跑和权限隔离 技术实现方案：通过DocumentLoader、Docum
2026-05-28 15:11:06
414
原创 LangChain4j 实战：JSON Schema、@Description、POJO 解析怎么配合
LangChain4j结构化输出实践指南 本文深入探讨了LangChain4j在Java项目中的结构化输出应用，重点解决企业级场景下的实际问题。主要内容包括： 核心价值：将AI模型输出直接映射为POJO/record/enum类型，实现后端系统无缝对接，避免自然语言结果难以处理的问题。 关键挑战： 字段名和枚举值不稳定导致规则判断错误 结构化结果异常导致链路中断 不同模型对JSON Schema支持程度的差异 解决方案框架： 通过Schema约束定义输出结构 使用注解增强字段描述 根据模型能力设计合理约束
2026-05-28 14:30:08
1022
原创 Java 做 AI 提取任务时，为什么我更建议先想好结构化输出
这篇文章我主要想讲清楚一个很实际的问题：很多 AI 项目不是卡在“能不能回答”，而是卡在“回答出来以后系统接不接得住”。所以我结合 Spring AI 的结构化输出能力，完整拆了 Prompt 模板设计、Java 实体映射、结果落库、解析失败兜底 这几块内容，并用售后工单分流的真实场景举例，说明为什么结构化输出才是很多 AI 应用真正能落地的关键。适合正在做 Java + AI、智能分类、工单分流、信息提取 这类项目的同学参考。
2026-05-27 14:36:30
365
原创 面试高频：Spring AI 统一聊天入口怎么设计，这次把路由和降级讲具体
Spring AI 中 ChatClient 的落地实践关键在于构建统一聊天入口、实现智能模型路由和建立完善的治理机制。文章指出，许多团队直接使用模型 Bean 导致调用分散，难以管理。解决方案包括：1）统一请求体和接口规范；2）基于场景、成本和性能的模型路由策略；3）Prompt 模板化确保输出一致性；4）超时降级和熔断机制保障稳定性。文中提供了代码示例，展示如何结合 ChatClient 和底层 ChatModel 实现这些功能，并强调监控指标（成功率、RT、token 消耗等）的重要性。最终建议将 C
2026-05-27 14:33:09
405
原创 医疗辅助决策系统怎么设计？一次讲清风险分层、知识增强、输出约束与医生确认机制
医疗辅助决策系统设计应遵循"AI增强而非替代医生决策"的原则。系统需具备风险分层、知识增强和输出约束三大核心功能：1)通过评分卡或规则引擎进行风险分级；2)整合临床指南等外部知识库增强建议可信度；3)明确区分参考建议、风险提示等输出类型。关键设计要点包括：确保结果可追溯来源、医生保留最终确认权、避免AI结论直接写入病历。系统定位应为医生工作流中的辅助信息层，而非独立诊断工具。代码示例展示了基于患者指标的风险评分实现，SQL部分演示了关键数据查询逻辑。医疗AI系统的核心价值在于提供有依据的辅助信息，而非替代专
2026-05-22 09:45:05
349
原创 为什么医疗质控特别适合 AI 先落地？
医疗质控AI系统设计的关键在于规则与AI的协同应用。文章提出采用"规则基线+AI增强+人工确认"的三层架构：规则层处理确定性缺失（如必填字段），AI层识别语义问题（如表述不规范），最终由医生确认结果。系统需包含质控规则库、AI辅助识别层、结果分级机制和医生确认闭环。典型应用场景包括出院小结的完整性检查，通过规则校验必填项，AI分析自由文本，生成分级提醒供医生参考。实现时需避免纯AI方案、直接修改病历等风险，确保结果可解释、误报可控。这种设计既发挥AI的语义理解优势，又保持规则的可控性，是医疗质控领域较稳妥的
2026-05-22 09:44:31
335
原创 面试官常问的医疗数据权限问题，这次终于讲明白了
本文系统探讨了医疗数据脱敏与权限设计的关键要点。作者强调医疗数据的敏感性，提出四大核心原则：最小必要、角色权限控制、脱敏优先和审计留痕。文章详细介绍了脱敏技术（掩码、字段移除等）和三层权限控制体系（业务系统、AI平台、输出审查），并指出常见误区如全量数据暴露、仅前端脱敏等。通过Java代码和SQL示例展示了具体实现方案，建议面试时可从最小必要原则、三层权限控制和访问审计三个维度回答相关问题。最后总结医疗AI系统的底线是"数据最小化、权限前置化、脱敏默认化、审计全程化"。
2026-05-22 09:43:57
402
原创 面试必问：医生辅助问答系统怎么设计？这次彻底讲透
《医生辅助问答系统设计要点》摘要： 医疗AI系统中最易落地的应用是医生辅助问答系统，其核心定位是知识辅助而非诊断决策。系统设计需把握三大关键：1）严格区分医生端与患者端功能边界；2）确保回答具备可验证依据（引用权威指南/文献）；3）建立完善的审计日志机制。技术实现上推荐采用RAG架构，通过知识检索增强模型回答的准确性，同时设置严格的提示词约束防止模型越界输出。特别要注意避免让模型自由发挥诊疗建议，所有回答必须标注来源并保持"辅助建议+医生判断"的协作模式。这种"知识增强+来源引用+输出受控"的设计思路，既能
2026-05-22 09:41:56
399
原创 面试必问：病历结构化怎么设计？这次彻底讲透
病历结构化设计要点：将临床自由文本转化为可计算数据，需遵循"模型抽取+标准化+医生确认"的闭环流程。关键设计包括标准字段定义、置信度评估、原文保留和人工确认机制。实现时先分段抽取关键信息，进行疾病/药品名规范化，再经医生审核后落库。医疗场景需避免全自动处理，保留原文与结构化结果的映射关系，确保数据可回溯。结构化结果应服务于质控、统计和辅助决策等后续应用。
2026-05-22 09:41:01
397
原创 面试必问：医学知识库 RAG 怎么设计？这次彻底讲透
医学知识库RAG设计需重点关注准确性、可追溯性和权限控制。医疗场景更适合RAG，因其知识具有明确来源、版本和时效性。关键设计点包括：谨慎文档切片（按章节/小节）、混合召回（关键词+向量）、带来源回答（引用片段+文档+版本）、权限前置处理（召回阶段过滤）。避免常见误区如切片过碎、无来源标记、知识更新不及时。实战中需结合指南检索、科室权限，确保回答准确可追溯。医疗RAG核心在于将知识正确、可追溯地提供给模型，而非单纯依赖模型能力。
2026-05-20 10:53:30
522
原创 面试必问：AI 医疗平台怎么设计？这次彻底讲透
本文从系统设计角度探讨了AI医疗平台的构建思路。作者提出AI医疗应优先定位为"辅助系统"而非"替代系统"，重点解决医学知识查询、文书处理、质控提醒和患者服务四大问题。核心设计原则包括辅助优先、知识可追溯、人在回路、严格权限审计和输出边界控制。平台架构应包含知识库中心、病历处理、问答生成、权限脱敏等模块，并强调医学知识库+RAG、权限脱敏、输出可追溯等技术亮点。文章还指出了自动诊断、知识边界缺失等常见误区，并通过代码示例展示了权限校验、知识检索和审计留痕的实现逻辑。最后强调AI医疗的关键在于确保知识可信、数据
2026-05-20 10:36:33
243
原创 Java 面试高频题：通知平台整体架构一般怎么拆？
本文系统梳理了消息实时通知平台的完整架构设计。作者指出成熟的通知平台应形成"渠道、模板、推送、回执、偏好、审计、监控"的闭环能力，而非简单叠加功能。核心模块包括通知接入层、模板中心、渠道适配层等9个部分，强调实时推送与持久化消息协同、MQ异步投递、已读回执体系等技术亮点。文章还提供了Java代码和SQL示例，并给出面试回答建议，指出平台价值在于可扩展、可追踪、可治理的能力。最终结论强调成熟通知平台需要六层能力协同运作，确保消息"发得出、发得准、发得稳、发得可追"。
2026-05-20 10:35:55
215
原创 面试必问：通知平台的监控与告警怎么设计？这次彻底讲透
本文系统讲解了通知平台监控告警的设计要点。作者指出通知平台最需要关注的是业务指标而非机器指标，关键监控应包括发送成功率、渠道健康度、回执延迟和失败追踪等。文章提出了四大关键告警场景和四个常见误区，强调要按渠道拆分指标并分级告警。通过Java代码和SQL示例展示了具体实现方式，建议面试时可从业务指标、渠道拆分和优先级设置三个维度回答相关问题。核心观点是：通知平台最有价值的监控在于业务链路的健康度，而非单纯的系统资源指标。
2026-05-20 10:29:47
209
原创 2026年5月最新乌鸫科技面经：低代码主子表、RBAC、统一支付接口设计都问到了
本文记录了作者2026年5月19日参加乌鸫科技面试的全过程。面试主要围绕项目经验展开，重点考察了RBAC权限系统、低代码主子表关联等实际项目难点，并深入探讨了Redis、MySQL、Spring等后端技术栈的应用场景和原理。面试最后还包含了一道系统设计题"统一支付接口设计"。作者反思认为，这场面试更注重考察候选人将项目经验、中间件使用和系统设计融会贯通的能力，而非单纯背诵八股文。文章详细梳理了面试各环节的问题及优化后的回答思路，为读者提供了项目经验表述和技术问题应答的参考框架。
2026-05-20 10:28:35
771
2
原创 德国和日本到底怎么去？留学、工签、蓝卡、双元制一次讲透
德国和日本出国路线对比：留学、工签、蓝卡等选择指南 本文对比分析了德国和日本两种主流出国路径，为普通本科背景的Java开发者提供实用建议。德国路线更适合长期发展，包括留学、工签、蓝卡、双元制等选择，但语言和生活成本门槛较高；日本路线更易先上岸，通过留学或技人国工作签进入，日语是关键但整体门槛较低。文章建议：想快速出国优先考虑日本，追求长期发展选择德国，并提供了详细的路径对比表和实用建议。
2026-05-19 10:35:44
470
原创 我是怎么刷 LeetCode通过华为OD 的：高效刷题方法 + 100 道推荐题单
本文分享了一个高效的LeetCode刷题路线，核心思路是"先刷高频题，再按题型分类，形成解题模板"。作者建议不要盲目刷题，而是分三个阶段：第一轮建立常见题型的解题模板；第二轮针对薄弱题型重点突破；第三轮进行限时模拟面试训练。文章推荐了100道高频题目，涵盖数组、字符串、双指针、链表、栈队列、二分查找、二叉树、图算法、动态规划和回溯等核心题型。每道题建议按照"独立思考-写出初步解法-学习题解-二刷复盘"的步骤进行，并记录题型标签、核心思路、边界条件和时间复杂度等关键信息。这种有重点、分阶段的刷题方法，能帮助面
2026-05-19 09:59:34
859
原创 外企德科对接华为OD真实面经：机考、人事、一面过了，二面为什么挂？
华为 OD 二面挂了之后，我把这次从外企德科来电、上机考试、人事面到技术一面、技术二面的全过程重新复盘了一遍。文章里不仅有真实时间线、机考通过率、面试问题和 coding 题目，还有我对这次失败最核心的反思：一面更像项目筛选，二面更看你能不能讲清技术方案、项目难点和线上排障思路。如果你最近也在准备华为 OD、Java 后端或类似技术岗面试，这篇面经应该会比较有参考价值。
2026-05-19 09:39:00
4509
3
原创 实时通知推送怎么设计？一次讲清 WebSocket、SSE、长连接与在线消息下发
本文系统讲解了通知系统异步投递与失败重试的设计方案。首先分析了通知异步化的必要性，指出同步发送会拖慢主业务链路。推荐采用"业务事件-MQ投递-异步发送-结果回写"的解耦架构，重点阐述了指数退避+最大重试+死信队列的合理重试策略。文章总结了四大关键设计点（幂等、状态回写、死信处理、渠道隔离）和常见误区，并通过Java代码和SQL示例展示了具体实现。最后强调通知平台设计应形成"发送-状态-重试-死信-补偿"的完整闭环，确保系统可靠性。
2026-05-18 10:56:46
181
原创 面试必问：用户通知偏好和订阅体系怎么设计？这次彻底讲透
本文系统探讨了用户通知偏好和订阅体系的设计要点。作者指出通知平台需要平衡发送能力与接收边界，避免成为骚扰平台。关键设计维度包括：场景偏好（如订单/营销通知）、渠道偏好（如短信/邮件）、时间偏好（如夜间免打扰）和强制通知标识。推荐采用"平台定义场景-用户保存偏好-发送前裁剪"的三层架构，确保业务逻辑与偏好判断解耦。文章强调必须设置默认策略、区分强制通知，并避免常见误区（如所有通知可关闭、仅前端控制偏好等）。最后通过Java代码和SQL示例展示了具体实现方案，为构建用户友好的通知系统提供了实践指导。
2026-05-18 10:55:44
307
原创 实时通知推送怎么设计？一次讲清 WebSocket、SSE、长连接与在线消息下发
本文系统介绍了实时通知推送的设计方案，重点分析了WebSocket、SSE和轮询三种实现方式的适用场景。作者提出"实时推送层+持久消息层"的双层架构，强调在线连接管理、多实例路由、离线消息兜底和已读同步等关键问题。文章还提供了Java代码和SQL示例，并给出面试回答建议。核心观点是实时通知系统需要兼顾在线即时触达和离线消息可靠性，而非单纯依赖长连接技术。
2026-05-18 10:52:08
199
原创 普通本科 Java 出海怎么走更现实？日本、德国、新加坡我会这样排
2026年普通本科Java开发者出海国家选择指南 本文针对普通本科Java开发者提供了三个可行的出海选择：日本、德国和新加坡。日本因其成熟的工签路径、较低的准入门槛和平衡的生活成本成为首推选项，特别适合作为海外职业发展的第一站。德国虽然前期难度较高，但长期身份价值和职业发展空间更大，适合有经验的开发者。新加坡虽然薪资诱人，但高生活成本和严格的工签要求使其更适合英语能力强、经验较丰富的中高级开发者。文章通过对比签证政策、薪资水平、生活成本和职业发展等关键因素，帮助开发者根据自身条件做出最优选择，并提供了实用的
2026-05-18 10:46:51
876
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人