- 博客(307)
- 收藏
- 关注
RSS订阅原创 一次性讲清：Thread / Runnable / Callable / Worker / 线程池（Java 并发不再混乱）
本文清晰区分了Java并发编程中的核心概念：Thread是真正的执行线程，Runnable/Callable只是任务代码，线程池通过Worker（Thread子类）循环执行任务。重点指出常见误区，如直接调用run()不会创建线程、Callable需通过FutureTask包装才能执行。文章强调线程与任务的本质区别——线程是执行资源，任务是业务逻辑，并解析了线程池的工作机制（Worker线程重复执行多个任务）。最后总结出关键认知：线程需池化管理，任务可无限提交，理解这一边界是掌握系统级并发思维的基础。
2025-12-25 18:53:18
350
原创 Flutter 路由从 Navigator 到 go_router：嵌套路由 / 登录守卫 / 深链一次讲透
Flutter路由管理的核心挑战在于如何优雅处理复杂场景。文章对比了Navigator 1.0/2.0的局限性，重点推荐go_router解决方案，其通过声明式路由和状态驱动跳转，系统性地解决了登录守卫、深链接入、页面栈管理等工程痛点。关键设计包括：将路由视为状态映射而非push行为、采用路由树结构、通过ShellRoute管理嵌套页面、集中式登录态控制等。文章还提供了真实项目路由结构模板，强调当项目涉及多模块、登录态和深链时，路由选择已从API问题升级为架构决策。go_router通过统一入口和状态驱动，
2025-12-25 17:39:31
465
原创 从前端路由到 Android ARouter：观察者模式在不同平台的同一种落地
路由系统的本质：观察者模式的跨平台实现 前端路由、Android ARouter和Flutter go_router虽然API各异，但核心都是通过观察"导航状态"（URL/路径/location）的变化，自动完成页面切换。它们都采用观察者模式：被观察者（URL/路由请求）变化时，观察者（路由系统）响应并执行组件渲染/Activity跳转/Widget切换。三者都演进为声明式路由，通过集中路由表+统一守卫（beforeEach/Interceptor/redirect）解决多入口和权限管控
2025-12-25 16:13:07
334
原创 从命令式跳转到声明式路由：前端、Android、Flutter 的一次统一演进
本文探讨了前端、Android和Flutter平台中路由系统的本质共性。作者指出，尽管各平台API和实现细节不同，但都采用了"声明式路由+全局导航治理"的核心模式。文章分析了命令式跳转在复杂项目中必然失控的原因，阐释了声明式路由将跳转行为转化为状态映射的思想转变。通过对比三种平台的路由实现（前端路由表、Android ARouter和Flutter go_router），揭示了它们共同的抽象维度。最后强调全局导航治理是复杂应用的必然选择，指出理解这一共性有助于快速掌握新技术。
2025-12-25 15:09:28
883
原创 Android（Kotlin） ↔ Flutter（Dart） 的“1:1 对应表”：架构分层来对照（MVVM/MVI 都适用）
Android与Flutter开发对应表（MVVM/MVI架构） 网络层： Retrofit ↔ Dio（HTTP客户端） OkHttp ↔ http包（底层实现） OkHttp拦截器 ↔ Dio拦截器（处理401 token刷新） 数据层： Room ↔ Drift（ORM数据库） Flow/LiveData ↔ Stream（数据监听） Repository ↔ Repository（统一数据出口） UI层： ViewModel ↔ Riverpod/Bloc（状态管理） LiveData观察 ↔ Co
2025-12-23 22:07:27
621
原创 用 Drift 实现 Repository 无缝接入本地缓存/数据库（SWR：先快后准）
本文介绍了在Flutter项目中使用Drift（原Moor）实现本地数据库缓存策略的完整方案。主要内容包括：1）Drift依赖配置；2）Profiles表结构设计；3）AppDatabase数据库初始化；4）ProfileDao数据访问层实现；5）DomainModel与Mapper转换层；6）远程API调用；7）Repository层实现"先本地后远程"的缓存策略；8）增加TTL过期机制；9）与401认证刷新的协同处理。该方案通过watch机制实现UI自动更新，采用upsert简化数据
2025-12-23 21:44:15
218
原创 Repository 层如何无缝接入本地缓存 / 数据库
本文提出了一套"先快后准"的数据策略，通过Repository层统一管理数据源，实现快速响应与数据更新。核心方案包括：1）采用Cache-Aside+Stale-While-Revalidate策略，先返回缓存数据再异步更新；2）提供两种接口：一次性读取和流式订阅；3）给出两种实现方案：基于DB作为单一事实源（推荐中大型项目）和基于TTL的缓存策略（适合中小项目）。文章还讨论了401自动刷新Token处理、常见工程问题及方案选择建议，强调Repository层应屏蔽数据源细节，为上层提供
2025-12-23 21:08:40
763
原创 401 刷新 Token 的队列版（请求挂起排队 + 刷新后统一重放/统一失败）
本文提出了一种基于队列的Token刷新中间件方案，用于优化中大型项目中并发请求时的Token过期处理。相比传统的共享Future方案，队列版通过请求挂起、统一重放和统一失败机制，解决了多请求并发刷新导致的401风暴问题。核心实现包括：Token存储管理、RefreshManager并发锁、请求队列管理，以及全局onAuthExpired回调确保统一登出。该方案特别适用于需要控制重放节奏（顺序/限流/去重）的场景，通过中间件语义实现了更工程化的异步并发控制，有效提升了弱网环境下的用户体验和UI一致性。
2025-12-23 13:56:08
119
原创 401 自动刷新 Token 的完整架构设计（Dio 实战版）
本文介绍了Flutter+Dio项目中处理并发401错误的优化方案。当多个请求因accessToken过期同时返回401时，通过共享Future机制确保只执行一次token刷新，避免刷新风暴。方案采用分层设计：AuthInterceptor负责注入token，RefreshInterceptor处理401并重试请求，TokenStore管理token存取，RefreshManager实现并发控制。核心原理是利用共享Future作为异步锁，使多个401请求复用同一个刷新操作，刷新成功后各自重试原请求。该方案简
2025-12-23 13:55:10
986
原创 Dio 工程化实战篇（拦截器 + 并发 + 错误设计）
本文系统介绍了Flutter项目中Dio网络层的工程化设计方法。核心要点包括：1）建立单例DioClient作为统一网络出口；2）将拦截器按职责拆分为认证、日志和错误处理三类，实现Token自动注入和错误统一映射；3）使用Future.wait实现安全高效的并发请求；4）UI层只需处理业务错误，无需关心网络细节。通过这种分层设计，可使网络层具备良好的可维护性和扩展性，避免UI层出现复杂的网络判断逻辑，提升整体代码质量。文章强调，合理的网络层架构是Flutter项目进入"工程阶段"的重要标
2025-12-19 12:30:27
794
原创 从 axios / Promise 到 Dio / Future：一次讲透 Flutter 的异步与并发模型
本文澄清了异步编程中的关键概念：Dio和axios本质都是基于Future/Promise模型的HTTP客户端，两者可互相迁移。核心指出async/await不等于并发，await仅实现函数内部串行执行而不阻塞线程，真正并发来自同时创建多个Future。文章对比了前端和Flutter在拦截器设计、并发处理（Promise.all/Future.wait）及错误处理上的异同，强调这是可迁移的通用能力模型。最后建议Flutter工程中采用显式写法而非JS式解构，为后续Dio实战篇打下理论基础。
2025-12-19 11:50:34
933
原创 从 Android 回调到 C 接口：函数指针 + void* self 的一次彻底理解
C语言通过结构体+函数指针实现回调机制，其本质与Java接口回调思想一致。文章以Android的setOnClickListener为例，类比解释C语言中通过Ops结构体定义接口、voidself传递上下文、函数指针绑定实现等关键概念。C语言虽无class/interface语法，但通过手工组装实现了面向对象的核心机制：接口定义（struct）、方法实现（函数指针）和上下文传递（voidself）。这种底层实现方式展现了不同语言间相通的工程思想，即通过约定实现解耦和多态。理解这种对应关系后，C回调的&quo
2025-12-18 16:30:51
256
原创 Java 的“高阶函数”到底是什么：Runnable / Callable 就是函数参数
摘要：Java通过函数式接口和lambda表达式实现了高阶函数的核心思想，虽然实现方式与纯函数式语言不同。Java将可执行行为封装为实现了特定接口（如Runnable、Callable）的对象，而非直接传递函数。这种设计保留了Java的类型系统和工程优势，同时提供了函数式编程能力。线程池的submit方法就是典型的高阶函数应用，它接收Callable对象作为参数并在未来执行。方法引用是lambda表达式的语法糖，使代码更简洁。Java的高阶函数本质是"用接口承载行为，用lambda实现"
2025-12-17 15:30:25
423
原创 Java 线程池（第十篇）：（收官篇）CompletableFuture 异步编排实战 —— 多任务并行、结果汇总、超时控制与线程池协作
本文介绍了CompletableFuture在Java并发编程中的核心价值与实践方法。作为异步任务编排工具，它通过声明式API解决了传统Future阻塞式编程的问题，提供了三种核心编排模式（链式变换、异步依赖、并行合并）以及allOf/anyOf并行控制。文章重点讲解了异常处理、超时控制等关键特性，并强调要配合专用线程池使用。最后指出CompletableFuture与线程池的关系：前者负责任务关系编排，后者提供执行能力，二者共同构建完整的并发编程体系。
2025-12-17 15:15:11
749
原创 Java 线程池（第九篇）：线程池背压体系（BackPressure）—— 为什么 CallerRunsPolicy 是“天然限流”？
本文探讨了线程池中的背压机制（BackPressure），指出线程池的核心风险在于任务持续涌入而非线程耗尽。文章将线程池本质定义为"生产者-消费者系统"，强调当生产速度超过消费速度时必然崩溃。通过分析JDK的四种拒绝策略，揭示它们实质是不同背压选择，其中CallerRunsPolicy通过让生产者线程自行执行任务实现自然背压，被推崇为最优方案。文章对比了RxJava的背压原理，指出两者都通过消费能力反向限制生产速度。最后强调无界队列等于没有背压，会引发系统崩溃，建议采用有界队列配合合理拒
2025-12-17 14:54:02
677
原创 Java 线程池（第八篇）：线程池可观测性设计 —— 如何监控线程池是否正在“慢性死亡”
摘要：线程池监控是防止系统慢性崩溃的关键。文章指出，即使正确配置了线程池，仍可能出现任务延迟、队列堆积等隐蔽问题。ThreadPoolExecutor提供了getActiveCount()、getQueue().size()等核心监控指标，建议定期采集活跃线程数、队列长度等6个关键指标。当出现活跃线程长期满载、队列持续增长等危险信号时，需要立即告警并干预。文章强调线程池问题不等同于CPU/内存问题，而是吞吐瓶颈，并给出了最小可用的监控实现方案，强调生产环境必须做到"可观测+可告警+可干预"
2025-12-17 14:34:53
489
原创 Java 线程池（第七篇）：线程池中的异常处理机制 —— 为什么异常会被“吞”？如何在生产中彻底兜住？
本文揭示了线程池任务中异常处理的隐秘机制：使用submit()提交任务时，异常会被Future捕获而不会自动打印，只有调用get()才会抛出，这容易导致"静默失败"。文章对比了execute()和submit()的异常处理路径差异，并提供了三种生产级解决方案：1）最推荐使用SafeRunnable包装任务内部捕获异常；2）框架级方案可重写afterExecute统一处理；3）特定场景下通过Future.get()显式获取异常。建议异常处理应就近完成，不要依赖调用方主动获取，以避免线上业务
2025-12-16 15:36:26
740
原创 Java 线程池（第六篇）：Runnable / Callable / Future / submit / execute 全解析：异步任务的正确使用方式
本文深入解析了线程池任务提交的核心问题。execute()和submit()的关键区别在于异常处理机制：execute会直接抛出异常，而submit将异常封装到Future中，只有调用get()时才会抛出。文章详细对比了Runnable（无返回值）和Callable（有返回值可抛异常）的差异，并指出Future.get()会阻塞线程的风险，建议配合超时控制和cancel(true)使用。特别强调生产环境中submit不调用get()会导致"吞异常"现象，推荐通过统一封装SafeRunna
2025-12-16 15:05:33
690
原创 从 C 链表到 Android Looper：MessageQueue 的底层原理一条线讲透
摘要：本文从C语言基础出发，通过链表和队列的数据结构演变，揭示Android消息机制的本质。首先解析指针和结构体的底层原理，说明链表的最小单元Node结构。进而引入Queue作为链表管理者，分析指针传递的关键点。重点阐述MessageQueue如何演变为按执行时间排序的消息队列，以及Looper通过无限循环和阻塞机制实现高效调度。最终建立C语言数据结构与Android消息组件的完整映射关系，帮助开发者从底层理解Handler/Looper的工作原理。
2025-12-16 11:20:01
773
原创 从悬空指针开始，彻底搞懂 C 语言的指针、free、NULL、栈与堆
函数内定义的普通变量生命周期跟随作用域自动分配 / 自动释放int a = 10;// 栈悬空指针：仍然保存着“已释放内存地址”的指针变量。*p = 2;free(p);// p 现在是悬空指针此时：p ──> 已释放/可复用的内存*p = 3;都是未定义行为（Undefined Behavior）正常数据错乱直接崩溃指针：存地址的变量栈：自动管理，跟作用域走堆：手动管理，malloc / freefree(p)：释放 p 指向的堆内存块悬空指针。
2025-12-16 08:45:00
1627
原创 Java 线程池（第五篇）：生产级线程池封装方案（统一命名、异常捕获、监控与超时控制）
本文介绍如何封装一套生产级线程池，解决常见痛点：统一管理线程池、线程命名、异常捕获、拒绝策略日志、监控与超时控制。通过自定义ThreadFactory实现线程命名和异常兜底，包装RejectedExecutionHandler记录拒绝日志并实现回压。核心ThreadPoolManager提供CPU/IO/定时三类线程池的统一出口，并封装SafeRunnable确保任务异常不丢失。此外还实现Future超时控制、简单状态监控和优雅停机机制。关键点包括：使用有界队列、统一线程池出口、线程命名、拒绝策略日志、异常
2025-12-15 16:27:38
637
原创 ScheduledExecutorService 行为观察 Demo（可直接跑）
本文演示了Java定时线程池中scheduleAtFixedRate和scheduleWithFixedDelay的区别。通过创建2线程的ScheduledThreadPoolExecutor，分别运行两个任务：一个使用FixedRate模式（固定间隔5秒），一个使用FixedDelay模式（执行后延迟5秒）。当任务执行3秒时，FixedRate保持5秒间隔，FixedDelay形成8秒周期；当任务执行7秒时，FixedRate会立即补执行，而FixedDelay保持"执行时间+延迟"的
2025-12-15 16:08:39
134
原创 Java 线程池（第四篇）：ScheduledThreadPoolExecutor 原理与定时任务执行机制全解析
本文深入解析Java定时任务核心组件ScheduledThreadPoolExecutor。作为ThreadPoolExecutor子类，它通过DelayedWorkQueue实现延迟任务调度，支持三种任务模式：单次延迟、固定速率(scheduleAtFixedRate)和固定延迟(scheduleWithFixedDelay)。文章详细对比了两种周期任务的本质差异：固定速率强调时间点执行可能导致任务堆积，固定延迟则确保任务间隔稳定。同时指出Timer已被淘汰的原因，并提供了典型代码示例。最后给出了不同场景
2025-12-15 16:03:54
742
原创 用 C 实现一个简化版 MessageQueue
摘要：本文用C语言实现了一个简化版的Android消息队列机制。核心思想是通过消息队列、循环处理和线程同步实现异步消息处理。实现包含消息队列初始化、消息投递(post)、消息获取(next)、消息循环处理(loop)和退出(quit)功能，使用互斥锁和条件变量保证线程安全。代码演示了生产者-消费者模型，生产者线程投递消息，消费者线程循环处理消息，展现了与Android MessageQueue类似的基本工作原理。
2025-12-15 15:40:33
296
原创 为什么 C 一定要用二级指针？一次彻底讲清
C语言函数传参默认值传递，修改指针参数时需用二级指针。文章通过链表头插示例说明：直接传Node*仅修改副本，外部指针不变；传Node**才能修改外部指针。关键场景包括链表初始化、头插删除等操作。文中提供错误与正确实现对比，并附可运行demo展示二级指针的实际效果。核心观点：要修改指针变量本身而非其指向的内容时，必须使用二级指针参数。
2025-12-15 15:33:18
720
原创 C 语言链表常见 10 大坑位（90% 初学者必踩）
摘要：本文总结了链表编程中常见的10个易错点，包括野指针、悬空指针、边界条件处理不当等问题。重点指出内存管理错误（如忘记初始化指针、释放后继续使用）、遍历条件错误（漏掉尾节点）、头节点处理不当等典型错误，并给出正确写法。同时提供了一个安全版本的链表实现模板，包含节点创建、头插尾插、内存释放等基础操作，强调二级指针传参和判空检查的重要性，帮助初学者避免90%的链表崩溃问题。（150字）
2025-12-15 15:20:25
607
原创 链表：一个被业务开发“隐藏”的基础数据结构
《链表的工程价值与实用场景》摘要：链表作为一种通过指针动态连接节点的数据结构，在Java/Android开发中虽不常手写但至关重要。其核心价值在于灵活组织不确定数量的数据，适合频繁插入/删除场景，如Android的MessageQueue和LRUCache实现。链表优势在于结构灵活性而非性能，每个节点包含数据域和指针域，通过head指针管理整体结构。系统层常避免链表因其内存碎片和缓存问题，转而使用环形队列等方案。正确使用链表的判断标准包括：数据规模不定、操作频繁、侧重灵活性。理解链表有助于解读框架源码和优化
2025-12-15 11:33:37
883
原创 C 语言函数：从 0 到 链表封装 --＞ 一次真正理解“数据 + 行为”的过程
本文系统讲解了C语言中函数与数据结构的核心关系。首先指出初学者常卡在函数、指针、结构体等概念间的困惑，强调C语言的本质在于用函数组织数据行为。文章从基础函数用法入手，逐步讲解指针的必要性（实现变量修改）、结构体操作规范（必须传递指针），最终完整实现链表操作（创建、插入、删除、释放）。通过链表示例展示了C语言的工程思维：结构体存储数据，函数定义行为。最后指出这种"数据+行为"的设计思想与高级框架（如Android消息队列）一脉相承，掌握函数封装结构体的能力才是真正编写C工程代码的开始。
2025-12-15 11:30:14
541
原创 C 语言结构体 + malloc：对象生命周期管理（系统层视角）
本文对比了Java和C语言中对象生命周期的管理方式。在C语言中，开发者需要手动完成对象生命周期的四个关键阶段：1)使用malloc分配内存；2)初始化对象；3)使用对象；4)通过free释放内存。文章详细介绍了如何用struct定义对象结构、malloc分配内存、指针操作访问对象、以及正确释放内存的规范方法，并提供了完整的对象生命周期实现示例。同时指出了常见的5个内存管理错误，强调"谁创建谁销毁"的工程原则。掌握这套手动内存管理机制是系统层开发的核心能力，也是理解高级语言对象模型的基础。
2025-12-15 08:15:00
2053
原创 一文吃透 C 语言结构体（struct）：从语法到内存模型
本文介绍了C语言中结构体(struct)的核心概念和使用要点。结构体是将不同类型数据组合成整体的方式，类似于Java中的对象。重点包括：结构体变量声明与访问(.操作符)、指针访问(->语法糖)、typedef用法、内存对齐规则、值传递与指针传递的区别等。文章对比了C结构体与Java类的差异，指出C结构体是"去糖版"的对象实现，所有内存管理和访问细节都需要手动处理。最后总结了常见易错点，如内存对齐、指针生命周期管理等注意事项。
2025-12-15 08:00:00
1090
原创 深入理解 Java 线程池（二）：ThreadPoolExecutor 执行流程 + 运行状态 + ctl 原理全解析
摘要：本文深入解析Java线程池ThreadPoolExecutor的核心机制，包括任务处理流程（核心线程→队列→非核心线程）、五大状态（RUNNING/SHUTDOWN/STOP/TIDYING/TERMINATED）及转换条件，重点剖析了ctl的高效设计（32位整数同时存储状态和线程数）。同时详解了Worker管理线程的方式，对比了shutdown()和shutdownNow()的本质区别（是否中断线程/执行队列任务）。掌握这些机制即可深入理解线程池的核心运作原理。
2025-12-14 09:15:00
799
原创 Java 线程池 ThreadPoolExecutor 全面入门（原理 + 核心参数 + 图解）（一）
Java线程池是并发编程的核心组件，通过复用线程解决频繁创建销毁线程的性能问题。ThreadPoolExecutor的六大参数（核心线程数、最大线程数、队列类型、空闲时间、线程工厂、拒绝策略）决定了线程池行为，其中队列类型直接影响任务调度方式。工作流程遵循"核心线程→队列→临时线程→拒绝策略"的递进规则。JDK提供的四种线程池实现各具特点，但生产环境建议手动创建线程池并使用有界队列。最佳实践包括：根据任务类型（CPU/IO密集）设置线程数、命名线程便于排查、合理选择拒绝策略等。掌握线程池
2025-12-14 09:00:00
1334
原创 Java 线程通信：彻底理解 wait / notify（原理 + 图解 + 实战）
Java多线程中的wait()、notify()和notifyAll()是经典的线程通信机制。wait()让线程在条件不满足时挂起并释放锁，进入等待队列；notify()/notifyAll()则唤醒等待线程重新竞争锁。使用时要确保在同步代码块中调用，并用while循环检查条件避免虚假唤醒。与sleep不同，wait会释放锁且必须在同步块内使用。常见错误包括认为notify会立即执行、错误使用if判断条件等。这套机制本质是条件等待，与RxJava背压思想类似，都是处理生产消费速度不匹配的流量控制问题。
2025-12-13 08:00:00
786
原创 Java 线程池（第三篇）：拒绝策略与生产级线程池调优指南
拒绝策略的核心目的：保护系统，避免过载雪崩。：抛异常：丢任务：丢旧任务CallerRunsPolicy（推荐）：回压线程池调优核心：根据任务类型决定线程数CPU 核数 + 1CPU × 2~3分拆线程池必须使用有界队列，不能使用 Executors 默认线程池监控线程池是保障服务稳定的关键。
2025-12-13 08:00:00
774
原创 Hybrid App 中 Token 鉴权到底怎么做？
本文提出Hybrid开发的安全分级策略：公共接口由H5直接请求，需登录的普通业务通过原生网络层代发（H5不接触Token），高风险操作必须原生处理并添加额外安全措施。核心原则是不让H5获取Token，通过JSBridge让原生应用处理敏感请求，从而避免XSS等安全风险。这种架构既保证安全性又简化前端开发，明确划分H5负责UI、原生负责安全层的职责边界，是企业级混合开发的最佳实践方案。
2025-12-12 12:37:11
599
原创 Modbus 寄存器表怎么设计？工业设备文档规范与最佳实践
本文介绍了专业Modbus寄存器表的设计要点：1. 基本结构应包含地址、名称、功能等8个要素；2. 地址规划要按功能分区，保持连续性；3. 数据类型需明确16/32位及符号处理；4. 要标注单位、缩放比例、权限和取值范围；5. 提供完整示例模板。通过规范的寄存器表设计，可显著提升设备文档专业性和调试效率。
2025-12-12 09:30:00
587
原创 Modbus 通讯失败排查指南：CRC 错误、无响应、超时、乱码全解决
本文针对工业现场常见的Modbus通讯故障，提供了一套完整的排查流程。首先列举了6种典型故障现象（无响应、CRC错误、乱码等）及其根源。重点提出了按优先级排序的排查步骤：①检查串口参数一致性（波特率/校验位）；②验证从站地址；③确认功能码支持；④核对寄存器地址范围；⑤处理CRC校验问题（线缆/干扰/接线）；⑥解决乱码问题（波特率/停止位）。最后总结指出，Modbus通讯问题本质源于参数不一致、线路问题或寄存器错误，并推荐了从波特率到硬件的逐级排查方法。该流程可直接应用于现场调试，能有效定位各类通讯故障。
2025-12-12 09:00:00
347
原创 Modbus 异常帧为什么会出现 83？它到底代表啥？
Modbus协议通过功能码最高位区分正常和异常响应。正常功能码（如03）加0x80（10000000）变为异常码（如83），表示执行失败。异常帧格式固定为[地址][功能码+0x80][异常码][CRC]。例如018302表示地址1的03功能请求异常，错误码02（非法地址）。所有异常码都是原功能码加0x80（如10→90）。这种机制使设备能明确反馈请求执行状态，通过功能码最高位是否为1即可判断响应类型。
2025-12-11 09:30:00
396
原创 Modbus 常见异常码（Exception Codes）全解析：设备故障如何从报文中判断？
Modbus RTU/TCP 在主站与从站通讯时，从站可能因为。本文将完整解析 Modbus 异常帧结构与所有常见异常码。判断从站是否拒绝执行命令。在工业环境中提升调试效率。你可以快速定位设备异常。确认寄存器地址是否写错。
2025-12-11 09:00:00
727
原创 Modbus RTU 响应帧解析指南：功能码 03、06、10 一篇讲透（含完整字节图解）
本文详解了Modbus RTU协议中三种主要功能码的响应帧解析方法。03功能码（读寄存器）响应包含数据区，字节数为寄存器数量×2；06功能码（写单寄存器）采用请求帧回显机制；10功能码（写多寄存器）仅返回起始地址和数量。所有响应帧均以地址+功能码开头，CRC结尾，数据以16位寄存器为单位解析。掌握这三种响应帧结构可解析95%的Modbus报文，为开发通用解析器提供基础框架。
2025-12-10 14:30:41
958
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人