自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(31)
  • 收藏
  • 关注

原创 Spring AI的代码,把我CPU干烧了

摘要:文章吐槽了Spring AI的代码设计问题,重点分析了其链式调用中对象职责模糊、命名混乱的问题。作者以一个聊天接口代码为例,指出prompt().user().advisors().stream().content()这样的调用链让人困惑:对象在调用过程中不断"变身"(从ChatClientRequestSpec到StreamResponseSpec),动词方法名(stream())却不产生预期的流式传输效果。对比几种更直观的设计方案后,作者认为好的API应保持清晰的职责划分和语义

2025-12-25 14:40:52 867

原创 AI大模型的终局:开源、商品化与电力之战

作者在文中预测了AI大模型竞争的走向和结局

2025-11-28 11:59:14 260

原创 Flutter 三种事件处理模式的设计思想解析及多语言对比

Flutter事件处理模式分析与多框架对比 本文深入解析Flutter的三种事件处理模式:组件自带事件属性、GestureDetector手势检测和Controller模式,剖析其"组合优于继承"等设计思想。通过与Vue、jQuery和Java Swing的对比,揭示Flutter独特的架构优势: 三种模式分别对应不同场景:简单交互、复杂手势和业务解耦 采用观察者、策略等设计模式实现灵活的事件响应 相比其他框架,Flutter具有更明确的抽象层次和统一的组合式架构 在响应式编程和状态管理

2025-11-20 12:41:45 820

原创 PostgreSQL的设计傲慢:为什么“强大“不能成为“难用“的借口

PostgreSQL的设计傲慢:功能强大不应成为用户体验差的借口 摘要: 本文批评PostgreSQL在用户体验上的设计缺陷,揭示其在"强大功能"光环下存在的实际使用问题。文章指出:1)GRANT ALL PRIVILEGES命令名不副实,无法授予真正完整权限;2)系统表命名与用户表冲突,缺乏合理命名空间;3)权限模型复杂却不提供渐进式学习路径。通过对比MySQL更直观的设计,作者质疑PostgreSQL团队以"设计哲学"为由忽视用户体验改进。核心观点是:优秀工具应在

2025-11-06 12:00:04 796

原创 软件系统复杂性暴增的原因及如何提高软件系统的价值

本文反思了软件系统开发中复杂性问题,指出系统价值常被技术实现掩盖。作者通过租房系统"带看"业务案例,揭示报表需求的本质不是数据统计,而是为使用者提供价值反馈闭环。文章溯源数据的原始使命,强调"查"是数据的终极价值所在。建议开发者应主动设计"洞察系统",在业务数据产生时就思考其最终要回答的问题,为不同角色提供其关心的洞察,使系统成为"有灵魂的智慧伙伴"。这为程序员提供了从功能实现转向价值创造的新思路。

2025-11-03 11:05:58 900

原创 【Spring Boot Starter 设计思考:分离模式是否适用于所有场景】

本文探讨了Spring Boot中starter+autoconfigure分离设计模式的适用性。作者分析了这种官方模式的优缺点,指出其存在依赖冗余、配置复杂等问题。通过对自动配置类本质的思考,认为传统分离模式在大多数场景下价值有限。文章建议自研Starter可采用更内聚的设计:将自动配置类直接包含在Starter包内,简化依赖管理,有选择地使用条件注解。只有在需要统一管理大量组件配置的特殊场景下,集中式autoconfigure设计才有其合理性。最后强调技术决策应基于实际需求,而非盲目遵循标准做法。

2025-10-31 18:35:42 1130

原创 【与 AI 共舞:我如何与自己和解,并选择了一种新的创作方式】

摘要: 作者在尝试规律性写作时,面临整理灵感的困难与使用AI辅助的伦理纠结。最终意识到,文章的核心价值在于独特思考而非文字形式,AI可作为“翻译官”加速表达过程。与其因追求完美而放弃记录灵感,不如借助AI高效输出粗糙但珍贵的思想。关键在于保持思考的原创性,而AI负责优化表达。这一方式降低了创作门槛,让更多有价值的见解得以传播。作者呼吁:先完成再完美,利用工具保存思想,才是更明智的选择。

2025-10-31 15:06:31 804

原创 【从一家饭馆开始,谈一谈对技术创业的想法】

商业定位的底层逻辑:从饭馆经营看技术创业 科技园区两家相邻餐馆的兴衰揭示了商业成功的关键:精准匹配用户需求结构。"成都美食"因丰富的菜品成为高频刚需的"员工食堂",而主打单一品类的"牛肉板面"因无法满足固定客流的复购需求而倒闭。这一现象映射到技术行业同样适用: 环境决定模式 蓝海市场(如新兴园区)适合做"通才"(一站式服务) 红海市场需要成为"专才",但需确保细分领域有足够需求密度 核心启示 不要试图改变用户

2025-10-17 00:15:00 764

原创 配置的前世今生:从逻辑中抽离,又与逻辑有限融合

软件开发中的配置管理经历了从硬编码到完全分离,再到有限融合的螺旋式演进。早期硬编码导致修改繁琐,随后配置被抽离为独立文件(.properties/XML/JSON/YAML),解决了灵活性问题。但纯静态配置难以应对多环境需求,于是逻辑以克制的方式回归——通过环境切换(Profile)和变量替换实现动态适配。理想的配置系统应具备层级结构、环境适配和参数化能力,同时避免复杂逻辑,保持"声明式"本质。这种在分离与融合间找到的平衡,体现了软件工程的成熟智慧。

2025-10-15 22:15:00 1317 4

原创 单元测试 vs Main方法调试:何时使用哪种方式?

单元测试与Main方法调试的合理选择 单元测试适用于验证业务逻辑、支持自动化测试和持续集成,特点是可重复执行且结果稳定。而Main方法更适合临时调试和API学习,如验证JWT或Redis操作等工具类功能。当需要Spring环境时,可使用@Disabled标记的测试类避免影响构建流程。关键区别在于:单元测试是长期质量保障,Main方法调试是临时验证工具。开发中应根据实际需求选择合适方式,避免将学习性代码混入正式测试套件。

2025-10-13 10:59:38 1116

原创 从“关灯吃面”开始:关于所有创作的乱想

《创作的本质:从“关灯吃面”看情感表达的艺术》摘要 本文通过分析“关灯吃面”这一经典文学片段,揭示了优秀创作的核心在于情感证据的呈现而非情感的直接宣告。文章指出,无论是文学、绘画还是摄影,成功的创作都遵循人类认知世界的“注意力机制”——聚焦核心情感,筛选关键细节,强化情感锚点。这种创作逻辑在现代AI的Transformer架构中得到技术印证,其“注意力机制”与人类艺术创作过程高度相似。文章为创作者提供了一套普适心法:成为情感考古学家,运用注意力透镜,寻找情感物理锚点,并信任受众的共情能力。最终指出,创作的本

2025-10-11 18:17:33 818

原创 使用docker compose部署若依前后端版项目 - [2] 后端部署记录

本文介绍了使用Docker部署后台项目的核心思路和具体实施步骤。首先讲解了Docker构建的分层原理,说明项目镜像如何基于基础层构建。然后详细说明了多环境配置处理,包括开发环境和生产环境的配置调整。重点介绍了Dockerfile的优化编写,特别是利用mvn dependency:go-offline命令提升构建效率。最后分享了Docker Compose编排技巧,通过健康检查机制确保服务依赖顺序。整个部署过程充分利用了Docker的分层缓存机制,并合理处理了多容器间的依赖关系,为项目提供了稳定高效的部署方案

2025-09-26 16:03:34 918

原创 编译时参数校验:一个基于注解处理器的构想

本文探讨了将Java参数校验从运行时提前到编译期的可能性。作者在肯定Hibernate Validator等现有框架价值的同时,提出基于注解处理器实现编译期校验的构想。通过自定义校验注解(如@NotNull)和对应的处理器,可在编译阶段生成直接的校验代码而非依赖运行时反射。这种方案可能带来性能提升、代码透明度、简化依赖等优势,但也面临注解处理器复杂度、IDE支持等挑战。文章还指出实现这类技术需要深入理解编译期代码生成机制,而非简单的注解处理。

2025-09-23 09:46:14 685

原创 Java 参数校验总结:Spring + Hibernate Validator 的那些坑(@Valid和@Validated傻傻分不清?)

本文总结了Spring+Hibernate Validator组合的参数校验实践要点。在Controller中,普通校验可直接写在参数上,对象内部校验需用@Valid或@Validated激活;在其他Bean中则必须类上加@Validated,对象校验只能用@Valid。分组校验在Controller中可灵活使用,但在其他Bean中不能写在参数前。文章指出这套校验体系存在设计混乱问题,表现为不同场景行为不一致,但因其作为事实标准仍需掌握使用。最后提供了校验场景对照表,帮助开发者规避常见问题。

2025-09-22 19:14:44 664 1

原创 系统设计:从“不得不”的冗余到“刚刚好”的优雅

《从技术思维到用户思维:打造高效的在线购物系统》摘要:优秀系统设计需突破技术思维局限,聚焦用户目标高效达成。文章对比了自底向上的技术思维(从数据库设计出发)和自顶向下的用户思维(从交互流程出发),提出"最小化用户努力"四大原则:延迟注册、渐进式分析、智能默认和分步披露。通过支持稀疏实体的数据库设计和微服务架构,实现按需取用信息。最终目标是让系统如同自然对话般隐形于用户体验中,使购物流程从繁琐的"使用系统"转变为简单的"完成目标"。

2025-09-16 12:15:35 756

原创 技术的默契:论专业软件在易用性与专业性之间的平衡

本文探讨了专业软件设计中"难用性"背后的深层逻辑。文章指出,专业软件的高门槛是一种刻意设计的安全特性,通过复杂性和学习成本筛选合格用户,防止鲁莽操作引发系统性风险。专业软件通过标准化命令行模式(如pull/run/ps/rm)建立专家用户的通用语言,降低认知负荷。真正的专业软件易用性体现在为正确用户提供恰到好处的力量与约束,而非简单的界面简化。最后,作者提出如何应对"婴儿式用户"的讨论,这些用户往往忽视警告、随意操作并将错误归咎于系统。

2025-09-08 11:48:21 746

原创 记录一次昨晚的踩坑经历

有时候,现实让我开始信一点神神鬼鬼的东西,巧合到邪门的程度,开始往神秘学上面搞

2025-09-05 17:37:06 185

原创 使用 Docker Compose 部署若依前后端分离项目 - [1] 前端部署记录(AI轻微润色版)

最后说说我对 AI 辅助开发的看法:AI 确实能提升效率,也能稍微拓宽我们的技能边界——好比原本技能范围是 600 码,现在能扩展到 660 码左右。你无法给 AI 提供有效的调试提示,AI 能帮你的也就有限了。用 AI 辅助开发经常遇到这种情况:它给出的答案往往不完整,如果你不提,它也不会主动提醒你可能遇到的问题。这是因为 Vue 是单页应用,很多路由在服务器上并没有对应的文件,所以需要把所有的路由请求都重定向到 index.html。这个配置也是 AI 生成的,但一开始并不能直接用,调试了好久。

2025-09-05 17:12:09 778

原创 使用docker compose部署若依前后端版项目 - [1] 前端部署记录

本文记录了作者使用Docker部署Vue3前端项目的实践过程。主要涉及多环境配置调整(.env文件)、解决Vite配置中环境变量读取问题、编写通用Dockerfile实现两阶段构建(Node打包+Nginx部署),以及配置Nginx反向代理解决API请求转发问题。文章特别指出Vue打包后开发环境的代理配置会失效,必须通过Nginx反向代理处理,并分享了try_files配置解决SPA路由问题。作者认为AI工具虽能提高效率,但需要使用者具备基础技术能力才能有效引导AI解决问题,否则容易陷入调试困境。整个过程体

2025-09-05 16:49:29 463

原创 使用docker compose部署若依前后端版项目--如何部署自己的项目

本文提供了将若依前后端项目部署到Docker容器所需的文件清单。主要内容包括:新增的docker-compose.yml主配置文件、MySQL和Redis的初始化文件、前后端项目的Dockerfile构建脚本,以及前后端项目为适应容器化部署所做的配置修改(如多环境配置、目录调整等)。特别提醒:后台项目需将上传目录挂载到宿主机,防止数据丢失。这些文件变更可作为参考,帮助用户将自己的项目部署到Docker环境中。

2025-09-03 14:20:25 291

原创 使用 Docker Compose 实现一条命令部署若依前后端项目(AI润色版)

摘要: 本文介绍了一套基于Docker Compose的一键式部署方案,可快速启动包含前端、后端、MySQL和Redis的完整若依(RuoYi)项目。只需执行docker compose up -d --build命令,即可自动完成环境构建与服务启动,无需手动配置。方案适用于演示交付、标准化部署及团队协作场景,要求主机已安装Docker并保持网络通畅。项目源码已开源,部署成功后可通过http://localhost:30080访问(默认账号admin/admin123)。该方案显著提升了部署效率与环境一致性

2025-09-03 12:05:03 516

原创 使用docker compose实现一条命令部署若依前后端版项目

摘要:本文介绍了一键部署Ruoyi前后端项目的Docker Compose方案。项目要求服务器安装Docker并保持网络畅通,通过git clone获取代码后,只需执行docker compose up -d --build即可自动构建并启动所有服务(包括MySQL、Redis、前后端)。部署完成后访问http://localhost:30080,使用admin/admin123即可登录。该方案适合快速交付或环境部署,源码已托管至GitCode并验证可用。

2025-09-03 12:00:28 181

原创 使用 Java SPI编译期注解处理器Processor实现类结构一致性校验【AI润色版】

【摘要】针对实体类变更导致相关DTO类更新遗漏的问题,作者提出一种编译期检测方案:基于Java注解处理器开发@Src校验工具。该方案通过@Src(Parent.class)建立类继承关系,在编译时自动校验子类字段是否全部存在于父类中。核心实现采用javax.annotation.processing.Processor分析AST,相比运行时方案更早发现问题,可避免传统代码审查的滞后性。技术验证显示,通过Lombok同源的编译期处理机制,结合javax.lang.model的API,成功实现了字段一致性校验,

2025-08-29 20:03:39 586

原创 使用 Java SPI编译期注解处理器Processor实现类结构一致性校验

本文提出了一种基于Java SPI机制的编译时类属性检查方案,用于解决业务实体类变更时相关类遗漏修改的问题。通过设计@Src注解,在编译阶段自动检查子类属性是否全部存在于父类中。核心实现采用javax.annotation.processing.Processor接口,通过注解处理器获取类字段信息并进行比对。当子类包含父类不存在的字段时,编译器会报错并提示差异字段,确保类间修改的同步性。该方案避免了运行时反射的限制,直接在编译期完成校验,有效预防了因业务变更导致的属性不一致问题。

2025-08-29 19:58:31 812

原创 软件行为与用户预期的一致性问题【AI润色版】

摘要 调试若依前端项目时发现配置80端口却运行在1024端口的问题。排查发现是Linux/macOS的"特权端口"机制限制:普通用户无法绑定1024以下端口。解决方法是以sudo权限运行,或改用高编号端口。文章对比了Vite的处理方式,建议开发工具应明确反馈权限问题而非静默修改配置,并讨论了健壮性与可预期性的平衡。最终建议开发环境优先使用非特权端口,工具应提供清晰警告信息。

2025-08-28 11:49:19 588

原创 软件行为与用户预期的一致性问题:健壮性不应是脱离用户预期的理由

摘要:调试若依前后端分离项目时发现前端启动端口被自动改为1024,尽管配置中指定为80。经排查发现,在Mac/Linux系统下,低于1024的端口需管理员权限才能绑定。测试表明: Vue CLI会静默切换至可用端口,易造成配置失效却无提示 Vite能正确处理权限问题或报错,行为更符合预期 建议此类工具应至少输出明确警告(如"权限不足,端口已切换"),避免掩盖问题根源。对比突显了错误处理机制对开发者体验的重要性——静默容错可能破坏配置的可预测性。

2025-08-28 11:40:24 474

原创 程序设计中的接口准确性与变更扩散问题的讨论

本文探讨了Java开发中对象局部更新的常见问题。通过一个分类更新接口示例,指出直接使用完整实体类会导致接口与业务设计不一致的问题。作者分析两种解决方案:1)使用专用DTO对象(安全但维护成本高);2)直接使用实体类(简单但安全性低)。进而提出设想:能否通过"收缩继承"语法或@Extract注解,实现仅继承指定字段的功能,既保证安全性又降低维护成本。目前Java语言尚不支持此类特性,作者认为这是一个值得探讨的设计优化方向。

2025-08-19 18:41:12 314

原创 吐槽:Mybatis和Mybatis Plus 分页功能设计问题

也吐槽过mybatis的分页功能,但是仔细看看,只能说它没有做分页功能,却不能说它提供了错误的API,因为他本身压根没有分页的功能。所以它的分页插件配置后的使用方式怪怪的。但它不应该提供一个见名知意的操作,但是结果是错误的。这就是最大的问题,框架提供了错误的API,没有按照它的名字得到正确的结果,而是需要额外的配置。这就像一辆车,踩下刹车刹不住,你告诉用户有一条线缆用户你没接,显然是不恰当的。如果你不配置分页插件,那么这个分页API执行的结果就是错误的。但它的分页相关的API是可以直接使用的。

2024-06-16 12:02:45 419

原创 干货:谈一谈观察者模式

观察者模式在软件设计中用的非常普遍,也有很多变化:如,发布订阅模式,事件总线模式,响应式设计,事件驱动等等。观察者模式有点像IOC,IOC有一个名字叫控制反转,观察者通过将主动权上交给被观察者来降低系统消耗,实现一样的功能。这些变型通常只是在观察者与被观察者之间增加了一些中间层,来统一管理观察者的注册,和被观察者的事件发布。观察者模式是逻辑上的概念,在代码上只是个接口实现,对象添加,方法调用的过程。观察者模式:将观察者,在目标那注册登记,当状况发生,通知观察者操作。观察者模式,可以从名字理解这种模式。

2024-06-13 11:00:53 391

原创 java枚举类型的默认排序

枚举类型是默认按创建顺序排的,不用定义比较器。

2024-06-12 11:13:26 618

原创 一看就懂:关于分布式CAP定理

一个分布式系统中,一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)这三个基本要求中,最多只能同时满足其中的两项。吐槽一句,这个定理有点废话的意思,与其他领域常说的三元悖论不一样,三元悖论中,三元通常都是希望达到的目标,需要做权衡和取舍,选择其中两个。其实生活中的各种工具等事物都是这样,出了问题,要不对付着用,要不不用。这个定理的关键就是理解这个P,简单理解就是断网,出错。那么不出错的情况下呢,就可以满足CA。不将就用了,即CP。

2024-06-10 21:30:03 341

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除