[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"articles-2-10":3},{"code":4,"msg":5,"data":6},200,"成功",{"list":7,"total":101},[8,21,30,39,48,57,66,75,84,92],{"id":9,"title":10,"slug":11,"summary":12,"wordCount":13,"readingTime":14,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":19,"likeCount":18,"commentCount":18,"publishTime":20},"2010884680939794434","Trie树介绍","jieshao-trie-shu","🌲 Trie树的核心特性 Trie树有三个基本性质： 根节点不包含字符，它作为所有字符串的起点。 从根节点到任意一个节点的路径上，经过的所有字符连接起来，就是该节点对应的字符串（或前缀）。 每个节点的所有子节点所包含的字符都互不相同。 它的核心思想是 空间换时间，通过将字符串的公共前缀合并存储，避免了大量无谓的字符串比较，使得查询效率在很多情况下优于哈希表。 🧱 结构与基本操作 一个典型的Trie树节点（TrieNode）通常包含两部分信息： 子节点指针：可以是固定大小的数组（如处理26个小写英文字母时使用长度为26的数组）或更灵活的映射（如Map），用于指向下一个字符节点。 结束标记：一个布尔值（如isEndOfWord），标记从根节点到当前节点的路径是否构成了一个完整的单词（而不仅仅是前缀）。 对Trie树的基本操作包括： 操作 过程描述 插入 从根节点开始，逐个字符处理待插入字符...",2273,7,"0","",2,0,494,"2026-01-13 09:20:39",{"id":22,"title":23,"slug":24,"summary":25,"wordCount":26,"readingTime":27,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":28,"likeCount":18,"commentCount":18,"publishTime":29},"2010880124117905409","评论脏词过滤：基于DFA算法的高性能动态过滤方案","dfa-guolu-suanfa-gaoxingneng","评论系统是内容平台和社交应用的核心功能之一，而脏词过滤是保障内容安全、维护社区氛围的关键技术。本文将详细介绍如何在SpringBoot中实现一个高性能、支持动态更新的脏词过滤系统。 一、背景与需求分析 随着Web应用的发展，用户生成内容（UGC）面临着严峻的内容安全挑战。脏词过滤系统需要满足以下核心需求： 高性能：处理海量用户评论时不能成为系统瓶颈 动态更新：脏词库需要支持实时更新，无需重启服务 准确性：准确识别敏感词，同时控制误判率 灵活性：支持多种处理策略（替换、拒绝、审核） 二、核心技术选型：为何选择DFA算法？ 在脏词过滤场景下，DFA（确定有限状态自动机）算法相比传统方法有显著优势。 2.1 传统方法的瓶颈 暴力匹配：遍历每个脏词检查文本是否包含，时间复杂度O(n*m)，随脏词数量增加性能急剧下降 正则表达式：编译开销大，动态更新困难，复杂匹配可能产生回溯问题 2.2 DFA算法...",7520,25,364,"2026-01-13 09:02:35",{"id":31,"title":32,"slug":33,"summary":34,"wordCount":35,"readingTime":36,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":37,"likeCount":18,"commentCount":18,"publishTime":38},"2009074534064386049","MySQL如何解决深度分页问题？","mysql-shendu-wenti-jiejue","在MySQL开发中，除了计数场景，深度分页（即LIMIT offset, size中offset值极大的分页查询）也是高频遇到的性能问题。比如“查询第1000页数据，每页10条”（LIMIT 9990, 10），常会出现查询缓慢的情况。下面详细讲解深度分页的问题根源及解决方案。 1. 深度分页的问题根源 先明确常规分页的实现方式：使用LIMIT offset, size，其中offset表示跳过前N条数据，size表示取N条数据。 问题核心：当offset极大时（如9990），MySQL需要先扫描并跳过前9990条数据，再取10条数据。即使查询条件有索引，也需要遍历索引到第9990条位置，才能定位到目标数据，导致IO开销大、查询效率低。 示例（低效查询）： 2.",2845,9,266,"2026-01-08 09:27:51",{"id":40,"title":41,"slug":42,"summary":43,"wordCount":44,"readingTime":45,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":46,"likeCount":18,"commentCount":18,"publishTime":47},"2009073429104357377","MySQL中count(*)、count(1)与count(字段名)的区别详解？","mysql-count-ziduanming-zhong","在MySQL开发中，计数是高频操作，而count(*)、count(1)和count(字段名)这三种常见的计数方式，常常让开发者混淆——它们的计数结果是否一致？执行效率有差异吗？该如何选择？本文将从核心逻辑、具体区别、效率对比、实践建议四个维度，彻底讲清三者的差异，帮你避开使用误区。 一、先明确核心：count()函数的本质 首先要厘清一个基础认知：count()是MySQL的聚合函数，核心作用是统计查询结果集中符合条件的行数。三者的差异根源，在于「统计范围」和「MySQL对其的优化逻辑」不同，而非函数本身的功能差异。 二、三者的具体区别：逻辑+示例验证 为了更直观地对比，我们先创建一张测试表并插入测试数据（包含NULL值，模拟真实业务场景）： 1.",2555,8,232,"2026-01-08 09:23:26",{"id":49,"title":50,"slug":51,"summary":52,"wordCount":53,"readingTime":54,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":55,"likeCount":18,"commentCount":18,"publishTime":56},"2008065130120671233","二分查找的两种核心类型：精准查找与近似查找（Java实现与场景分析）","java-chazhao-jinsi-jingzhun","二分查找的两种核心类型：精准查找与近似查找（Java实现与场景分析） 前言 二分查找（Binary Search）作为有序数组的高效查找算法，其时间复杂度为O(log n)，远优于线性查找的O(n)。根据查找需求的不同，二分查找可分为两大核心类型：精准查找与近似查找。精准查找是二分查找的原始形态，专注于判断目标值是否存在并返回其精确索引；近似查找则是精准查找的扩展，用于在目标值不存在时，找到与目标值最接近的元素，满足实际业务中的模糊匹配需求。本文将详细讲解这两种查找类型的原理、Java实现及适用场景。 一、 精准查找（Exact Binary Search） 1.",7161,23,205,"2026-01-05 14:36:49",{"id":58,"title":59,"slug":60,"summary":61,"wordCount":62,"readingTime":63,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":64,"likeCount":18,"commentCount":18,"publishTime":65},"2008058850450665474","Vue3 应用版本更新策略：实现浏览器自动加载最新内容","liulanqi-celue-shixian-gengxin","本文将详细介绍如何在 Vue3 应用中实现版本更新后浏览器自动加载最新内容的完整方案，涵盖构建优化、缓存策略与版本控制的各个方面。 1. 构建工具配置：静态资源哈希命名 在 Vue3 项目中，使用 Vite 或 Webpack 等构建工具为静态资源生成带哈希值的文件名是版本控制的基础。当文件内容变化时，哈希值会更新，浏览器会因 URL 不同而重新加载资源。 Vite 配置示例 实现原理：Vite 在构建过程中会自动为资源文件附加哈希值，确保客户端能够加载最新资源，减少浏览器缓存影响。这种基于内容哈希的命名方式，可以精确控制缓存：只有当文件内容实际发生变化时，URL才会改变，从而触发浏览器重新下载。 进阶配置：生成版本信息文件 除了哈希命名外，还可以在构建时生成版本信息文件： 在 package.json 中配置构建命令： 2.",7286,24,179,"2026-01-05 14:11:51",{"id":67,"title":68,"slug":69,"summary":70,"wordCount":71,"readingTime":72,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":73,"likeCount":18,"commentCount":18,"publishTime":74},"2008024308121661442","二分查找算法和实例介绍","erfen-chazhao-shili-suanfa","1. 核心思想 二分算法是一种高效的搜索算法，适用于有序数组，通过分治策略逐步缩小搜索范围。其核心思想是： 将数组分为两半，比较目标值与中间元素的大小关系； 根据比较结果，决定继续在左半部分或右半部分搜索； 重复此过程，直到找到目标值或确定其不存在。 2. 使用前提 数组必须有序（升序或降序）。 适用于静态数据（无需频繁插入\u002F删除），因动态数据维护有序性成本较高。 3. 算法步骤 以升序数组为例，查找目标值 target： 初始化：定义两个指针 low（起始位置）和 high（结束位置）。 通常 low = 0，high = 数组长度 - 1。 循环条件：当 low \u003C= high 时继续循环。 计算中间位置： mid = (low + high) \u002F 2（或 mid = low + (high - low) \u002F 2 避免溢出）。 比较中间元素： 若 arr[mid] ==...",1858,6,156,"2026-01-05 11:54:36",{"id":76,"title":77,"slug":78,"summary":79,"wordCount":80,"readingTime":81,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":82,"likeCount":18,"commentCount":18,"publishTime":83},"2005630101352411138","场景面试题：如何避免用户重复下单（多次下单未支付，占用库存）","dan-yonghu-zhongfu-danwei","Spring Boot 如何避免用户重复下单（多次下单未支付，占用库存）？—— 面试题详解 在高并发电商系统中，一个常见的问题是：用户短时间内多次点击“下单”按钮，生成多个未支付订单，导致库存被无效占用，影响其他用户购买。这不仅浪费系统资源，还可能引发超卖或库存不足的问题。 本文将围绕 Spring Boot 技术栈，从原理、方案设计到代码实现，详细讲解如何有效防止用户重复下单，并形成一套可落地的解决方案。 一、问题场景还原（面试题背景） 面试官提问： “在我们的电商平台中，经常有用户在未支付的情况下多次点击下单按钮，造成多个待支付订单和库存锁定。请问你如何在 Spring Boot 项目中解决这个问题？” 这是一个典型的 幂等性 + 库存管理 + 分布式锁 综合问题。 二、核心思路分析 要解决重复下单问题，需从以下维度入手： 前端防重（基础但不可靠） 后端接口幂等性控制 库存预占与释放机...",4894,16,122,"2025-12-29 21:20:52",{"id":85,"title":86,"slug":87,"summary":88,"wordCount":89,"readingTime":63,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":90,"likeCount":18,"commentCount":18,"publishTime":91},"2005627729460916226","什么是 Netty，它在网络编程中解决了什么问题？","netty-biancheng-jiejue-wangluo","Netty 是一个高性能、异步事件驱动的网络应用框架，用于快速开发可维护的高性能协议服务器和客户端。它由 JBoss（现为 Red Hat 的一部分）开发，并广泛应用于 Java 生态系统中，是构建高并发、低延迟网络应用的重要工具。 一、Netty 是什么？ Netty 是基于 Java NIO（Non-blocking I\u002FO）封装而成的网络编程框架。它屏蔽了 Java 原生 NIO 编程的复杂性，提供了更简洁、更安全、更高效的 API，使得开发者可以专注于业务逻辑，而无需处理底层网络通信细节。 核心特点包括： 异步非阻塞：基于事件驱动模型，支持高并发连接。 高性能：通过零拷贝、内存池、高效的线程模型等优化手段提升性能。 可扩展性强：模块化设计，支持自定义协议、编解码器、处理器等。 稳定性高：经过大量生产环境验证（如阿里巴巴、Facebook、Twitter 等）。 社区活跃、文档完善：...",7367,91,"2025-12-29 21:11:25",{"id":93,"title":94,"slug":95,"summary":96,"wordCount":97,"readingTime":98,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":99,"likeCount":18,"commentCount":18,"publishTime":100},"2005275234708549633","Spring Boot中.properties和.yml 的配置文件区别是什么？","spring-boot-properties-yml","在 Spring Boot 中，application.properties 和 application.yml 都是用来配置应用程序属性的配置文件，它们的功能是等价的，只是语法格式不同。以下是两者的主要区别： 1. 语法格式不同 application.properties 使用键值对的形式（类似 Java 的 Properties 文件）： application.yml 使用 YAML（YAML Ain't Markup Language）格式，基于缩进表示层级结构： 2. 可读性与维护性 YAML 更易读、更简洁：对于嵌套配置（如 Spring Boot 中常见的多层配置），YAML 通过缩进清晰地表达层级关系。 Properties 更传统、兼容性好：适用于习惯使用 .properties 格式的开发者或工具。 3.",1734,5,80,"2025-12-28 21:50:45","43"]