grey_csdn-CSDN博客

原创 1932_关于AI Agent的一些尝试与体会

近期作者集中体验了多款AI Agent工具。最先接触OpenAI的Codex，因网络限制起初抗拒，后发现可接入DeepSeek等兼容OpenAI API的本地模型（如千问3.6系列），遂开始使用。随后尝试VS Code插件Continue，但未能成功接入；而Cline则一次配置成功，成为日常主力，辅助代码开发与分析。千问Code体验一般，TRAE因资源占用过高被放弃。Claude Agent虽编码能力强，但未体验原生状态。Open Code和Continue类似，折腾未果。新发现的Pi A

2026-07-30 22:23:15 172

原创 1931_日常应用的主力模型切换成 Qwen 27B

本文分享了作者近期使用千问35B-A3B和27B两个本地大模型的实际体验对比。作者发现35B-A3B虽然输出效率高（每秒token数多），但在高频使用时存在输出不稳定问题。转而尝试27B的IQ3量化版本后，通过调优实现了48K上下文支持（显存占用14.6G），保持25token/s的速度，在代码编写等任务中表现稳定。文章详细记录了参数配置过程，包括上下文压缩、线程设置等优化手段，并附带了启动脚本。作者特别指出27B模型在解决复杂问题时消耗token更少，尽管总耗时略长，但实际体验差距不大。最终在RTX508

2026-07-28 17:53:57 216

原创 1930_再论本地大模型处理音视频

本文总结了作者在本地部署大模型进行音视频解析的探索过程。最初尝试使用千问3.6-35B-A3B模型时发现其仅能通过截图进行图像识别，无法有效解析音频信息。随后尝试部署谷歌Gemma4 26B-A4B模型，虽能完成任务但处理时间过长。测试中意外发现该模型代码生成速度快且质量不错，适合作为编程辅助工具。最终作者得出结论：从实用性和经济性角度看，使用云端API可能更合适，但本地部署的探索过程本身积累了宝贵经验。这种技术尝试的价值不在于节省成本，而在于过程中获得的知识积累。

2026-07-26 23:29:19 233

原创 1929_使用本地 AI 大模型处理会议录屏长视频

本文作者分享了使用本地A3B多模态模型处理会议视频纪要的实践。由于硬件限制（仅支持128K上下文），作者通过Python脚本将长视频分割为30秒片段分别处理，为每个片段生成带时间戳的Markdown记录，最后合并汇总并进行总结。该方法成功处理了AI教程录屏，验证了在有限资源下通过分段处理实现长视频内容分析的可行性，展现了本地AI模型处理会议纪要的潜力。整个方案充分利用现有硬件条件，通过技术变通实现了原本难以完成的任务。

2026-07-26 23:13:16 237

原创 1928_llama.cpp部署Qwen 3.6-35B-A3B扩充识图功能

之后把我原来的启动脚本，以及我现在的电脑的配置信息情况，以及新的模型文件等等相关的信息，直接扔给 DeepSeek，让它给我修改启动脚本。测试了一下识图以及推理结合的状态之下，我的这个大模型的配置，目前的 Token 生成速度每秒钟成了 40 多个，现在的性能只有原来的大概一半。结合之前的一些使用体验来说，我觉得这一个速度基本上也是可以保证我工作之中尝试拿来做做简短的代码分析，或者是写点简单的代码框架，很好的一个速度保证，不会对我整体的使用体验有太大的影响。以上是我这次增加的识图的模型，来自于魔搭社区。

2026-07-26 10:04:31 252

原创 1927_关于这几天使用AI大模型辅助工作的一些经历与想法

本文作者分享了近期使用本地AI大模型（千问3.6-35B-A3B）的实践体会。通过测试不同量化版本，发现推理速度比精度更重要，可通过输入控制弥补精度损失。在对比Claude蒸馏版、DeepSeekV4Flash等模型处理复杂代码任务时，原版A3B表现最优。实验表明，当任务过于复杂时，AI容易陷入无效循环，而将需求拆解为清晰框架后，免费版DeepSeek仅用3分钟就完成了编码工作。作者认为当前AI更适合作为"高效工程师"角色，人类仍需担任架构师，提供明确规划。未来计划继续优化本地模型的视图

2026-07-23 23:17:48 187

原创 1926_RTX 5080 laptop显卡部署Qwen 3.6-35B-A3B模型支持128K上下文

本文记录了作者在本地部署千问3.6-35B-A3B大模型时的参数优化过程。作者最初遇到32K上下文限制的瓶颈，通过调研发现可通过调整MoE推理专家分配来扩展上下文。经过多次测试，作者在256K上下文下实现35 tokens/s的速度，但最终调整为128K上下文以获得更优的57 tokens/s推理速度。文末提供了优化后的启动配置参数，包括使用--mlock参数防止内存回收导致降速，展现了在上下文长度与推理速度之间寻找平衡的完整调优过程。

2026-07-21 00:46:11 236

原创 1925_结合本地部署大模型的AI_Coding_Agent使用体验

本文记录了作者探索AI编程工具的使用体验。通过对比测试，作者发现Cline在代码编写、自动测试和纠错方面表现优于Continue等工具。在本地模型方面，测试发现小参数模型虽然偶尔出错但能完成任务，验证了节省Token的可行性。当前主要瓶颈是32k上下文限制，下一步计划优化配置以支持更长上下文。整体而言，Cline展现出更强的智能化和流畅性，甚至能辅助发现代码错误，成为作者推荐的首选工具。（149字）

2026-07-20 20:03:14 229

原创 1924_千问A3B模型实用性的体验

本文分享了在本地部署千问3.6-35B-A3B大模型（IQ3量化版）的体验，其推理速度可达80-100 token/秒。作者发现该模型虽在原始能力上有限，但通过Agent框架（如Codex、TRAE）和VS Code插件（Cline）能有效提升开发效率。特别探索了多模态潜力，计划结合语音转文字、FFmpeg等工具实现会议纪要自动化处理，将文字、截图等信息交由模型整合分析。初步测试显示该方案具备可行性，为办公场景的AI应用提供了新思路，具体效果有待进一步验证。

2026-07-19 20:08:10 269

原创 1923_Qwen 3.6-35B-A3B的本地部署与调优

本文记录了作者在本地部署大模型的实践过程。作者先后尝试了千问3.6-35B-A3B的四比特和IQ3量化版本，通过参数调优将生成速度从40token/s提升至80+token/s，峰值可达130token/s。在测试文档编写、代码生成等场景时表现出色，虽不及顶级模型但已能满足日常需求。作者特别分享了优化后的启动配置参数，并强调AI工具应作为辅助而非完全替代人力，建议采取人机协作的工作模式。最终获得的模型性能已满足当前需求，下一步将重点考察其实际生产力提升效果。

2026-07-18 23:49:24 260

原创 1922_在拥有独立显卡的电脑上尝试本地大模型

本文作者分享了自己从云端AI工具转向本地大模型部署的探索历程。最初因云端API费用高昂而考虑本地方案，经过反复测试比较，最终选择了千问35B-A3B和27B量化版本模型。在部署过程中遇到GPU工作异常问题，最终通过DeepSeek分析解决。实际测试显示，27B模型虽性能稳定但硬件负载高，而35B-A3B在性能和噪音控制上更平衡。作者计划未来几个月继续探索与本地大模型的"共生合作"，为新工作模式积累经验。整个过程体现了技术选型的实用主义考量，以及解决问题过程中的曲折与收获。

2026-07-18 15:38:51 293

原创 1921_关于AI大模型本地部署以及API token购买的一些想法

我发现只要是运行微软的这个小模型，CPU 就是 100%，这个我是理解的。我知道这很大的原因是因为我的电脑配置不行导致的，于是我就想去尝试搜索一下，配置一个大模型，表现比较好的那种，需要什么样的电脑配置。但是它就是停下来了。即便是这样，在对比的过程之中我也总有一种冲动，去直接把我想要写的脚本需求贴到 DeepSeek 的官网上的 chat 窗口里，或者直接发给豆包。我自己总结出来的经验可能还是，如果是比较重要的事情，自己的确需要这种深度分析，而且需要一定的工作流的时候，那就直接去买 API token。

2026-07-04 22:11:55 260

原创 1920_Codex简单试用

文章摘要：作者近期尝试弥补AI技术短板时注意到Agent工具趋势，在众多选择中经推荐尝试Codex。由于访问限制问题，转而使用本地大模型DeepSeek，通过Codex++方案成功接入。测试发现，相比直接使用网页版聊天窗口（包括DeepSeek、豆包和阿里千问），经过Codex处理后的天气查询结果在排版、可读性和内容丰富度上显著更优，但API消耗较大。作者认为本地部署或第三方服务结合Codex可提供质量与成本的平衡选择，并附上了官方查询与Codex加工结果的对比截图。

2026-07-04 14:30:51 252

原创 1919_借助于AI生成树莓派瘦身脚本

本文作者分享了自己从对AI工具持怀疑态度到认可其价值的转变过程。最初因百度文心等早期AI工具存在幻觉问题、错误率高而长期排斥使用。但随着DeepSeek等国产大模型的快速迭代，尤其是其在代码编写、文件分析等方面的出色表现，作者开始重新评估AI工具的价值。通过实际应用案例（使用千问清理树莓派磁盘空间）展示了当前AI工具的高效性：仅用两轮提示就生成了完整的清理脚本，使磁盘使用率从90%降至52%。文章详细记录了与AI的完整交互过程，包括提示词和生成的脚本内容，证实了现代AI已能有效提升工作效率。作者最终得出结论

2026-07-02 23:38:59 261

原创 1918_Linux内核中的链表操作

本文探讨了多种链表数据结构实现方案的优缺点。作者回顾了CDA框架、FreeRTOS和严蔚敏教材中的数组链表实现，指出其复用性不足的问题。重点分析了Linux内核list.h的设计，该双向链表实现具有独立性和实用性，包含初始化、节点插入/删除、结构体指针获取、遍历迭代等核心操作。通过测试代码验证了链表首尾操作、空判断等功能，展示了如何利用list_add_tail实现队列机制。测试结果表明该实现能正确处理正向/反向遍历、节点删除和尾部移动等操作，具有较高的可靠性和实用性。

2025-06-28 13:08:10 917

原创 1917_PVE虚拟机使用初探

体验上是一种虚拟桌面的方式提供不同操作系统的使用体验，而不同的操作系统有不同的特点。我的虚拟机无法连网，后来使用英特尔的模拟方案，这个问题就解决了。也有人将半虚拟化的方式改为英特尔的模拟方式，然后再修改回去，最后结果是生效的。我最近的台式机希望退居二线，这为我提供了一个优秀的硬件平台。整体而言，安装的步骤与之前使用操作系统时的操作系统不同。在这样的环境中也可以去尝试一些新鲜一点的用法，这是一个非常好的体验。关于这个平台的使用，我的想法是服务上以Linux为主，辅以轻度windows系统弥补偶尔的不足。

2024-08-25 18:31:26 1345 1

原创 1916_大量数据备份的一点体会

相比于压缩或者打包来说，我们使用的SSH传输备份方式是直接将文件传输到宽带带宽上，因此并不占用磁盘空间。这样的资源消耗非常低，而且还有内存、CPU的消耗都比打包压缩占用的资源低很多。公司的采购流程非常慢，这段时间为了公司能够有一台可以自由安装软件的电脑，我计划将自己的电脑暂时放到公司用一下。无论是压缩还是纯粹打包，我都遇到过文件报错问题，要么是路径太长，要么是其他原因。我们尚未找到非常好的避免这样的问题的方案，只能尝试其他方法。当然，这个也不完全是仅仅静默的后台，如果我想查看它的速度，也可以查看。

2024-08-25 17:46:43 580

原创 1915_开源C语言实现的通用队列

经常在工作中遇到一些队列处理的场景，以前要么是借用FreeRTOS这样的系统中的相关功能，要么是通过数组做一个简单的队列模型。但是，这两种方案都具有一定的局限性能，前者要求的FreeRTOS不见得相应的软件中有，而后者只能够是设计专用的功能。这里只是做了一个简单的功能性的尝试，这个模块的优点还在于具备了类似FreeRTOS的复用性。有这样的功能之后，一些嵌入式中的处理功能写起来就更加得心应手了。就这个模块库提供的基本功能来说还是很全面了，尤其是针对小型的嵌入式系统，提供的这种静态创建的方式非常不错。

2024-08-10 15:44:28 1357

原创 1914_XCP的几种标定实现概念整理

在批量数据更新的时候，可以通过工具进行标定数据的地址偏移，将地址偏移到FLASH区间或者通过刷写的上位机进行地址的偏移转换。其中，FLASH的指针表可以固定在FLASH中，RAM的指针表可以用于标定的切换或者依然索引FLASH原始数据。页面切换的效率大大提升。这种方式，需要进行标定的参数存储在Flash中，以全局量的形式呈现，不进行额外的RAM分配。再加上MCU支持分页的映射，因此整个标定数据可以拆分成若干标定的子页面，根据标定的需求使能FLASH到RAM的映射，能够在很多使用场景下降低标定RAM的使用。

2024-08-10 15:37:45 1597

原创 1913_PowerShell中查看软件的版本信息

它在不带任何参数的情况下打印计算机上安装的所有 cmdlet、函数和别名。Format-List cmdlet将命令的输出格式化为属性列表，其中每个属性显示在单独的行上。有了linux上的一点点经历，遇到一些软件版本信息查看的时候我一般会通过command -v或者command --version等来试试运气。这个版本跟我直接从emacs的内置命令获取到的版本信息是一致的。由于列表相比于表格来说更容易显示更多的信息，因此PowerShell在列表中显示对象的更多属性，并且属性值不太可能被截断。

2024-03-26 08:23:24 1179

原创 1912_PowerShell的几个目录相关的命令

这个命令可以看做是bash命令中的ls的对等功能，如果是CMD使用的比较多可能也会有人会想到dir，而dir、ls其实也是这个命令在PowerShell中的别名。找一个目录中内容多的目录分别看一下两个命令，输出的结果是完全不同的。上面这两个可以按照linux中的pushd以及popd的方式来使用，如果是经常在终端模式做一些处理工作并且需要在不同目录间进行切换，这一组命令还是比较实用的。使用的时候直接使用别名cd比较好，这个正好跟bash、cmd等操作重名，并且完成的目的也是一致的。

2024-03-26 08:18:07 1300

原创 1911_野火FreeRTOS教程阅读笔记_请求任务切换

之后呢，寻找更高优先级的任务，让更高优先级的任务执行。因此，我们的PendSV的Handler中需要完成这个信息的更新。而这里的中断处理涉及到FreeRTOS的中断模型，其实也类似于AUTOSAR OS中的一类中断和二类中断。其他的都是关于逻辑的方法的，其实直接拿成熟的代码直接看或许更好一些。因此，在当前的PendSV阶段，我们需要做好任务优先级判断的处理，确认接下来需要执行哪一个任务。从这部分文档的描述看，其实这个PendSV的作用是非常固定的。这部分的处理，与SVC的处理其实是类似的。

2024-03-07 08:20:42 920

原创 1910_野火FreeRTOS教程阅读笔记_prvStartFirstTask函数

而返回之后，由于之前的SVC等已经设置了PSP的信息，因此接下来的软件会按照PSP中的设定去执行。为什么能够启动，结合之前梳理的任务创建的分析是可以理解的。因为任务创建的时候，把执行入口绑定到了TCB的栈中，在这次的退出时会返回执行。这是上面提到的表17。至于为什么要写入0xD，其实有其他的原因，因为这里的这段代码是一个异常的Handler。这里描述的事向量表的内容，向量表的0地址偏移处刚好是SP的初始值。vPortSVCHandler代码中的信息，代码到124行，其实是获取了当前任务TCB中的栈顶信息。

2024-03-07 08:18:55 1479

原创 1909_Arm Cortex-M3编程模型

这个表格是对上面信息很好的一个总结，当我看完前面的信息之后看到这个表格的时候我觉得，可能以后回看前面的内容是没有太大必要的，这个表格基本上就可以给我大部分关键的信息。可中断继续指令是针对加载多条指令的一种中断情况，执行LDM以及STM的时候处理器会执行暂停以及继续的操作，此时，中间的临时状态会存储在EPSR中。常见的CMSIS是Cortex系列的MCU软件接口标准的缩写，提供了对应寄存器的访问，也提供了便于RTOS内核开发的标准接口。块中的每条指令都是有条件的。指令的条件要么是相同的，要么是相反的。

2024-03-06 06:44:12 1438

原创 1908_Arm Cortex-M3的实现

而OS等方面的一些功能基本上都是用了现成的解决方案，因此也就没有过多的关注。这一次是按照STM32F103的手册来看的这一份文档，虽然不见得通用，但是应该共通之处非常多。以上这部分算是从这个手册中读到的比较令我觉得需要关注和注意的点，继续往下的一个章节是编程模型，应该是我着重看的一个章节。前面刚好看了M3的DS，结合那一份文件的经验，上面划出来的DAP应该是连接到总线上的，但是这里的示意图是没有画出来的。中断响应的延迟低是靠硬件来实现的，在软件实现的时候也不需要写过多的汇编相关代码。SCB：系统控制模块。

2024-03-06 06:41:24 620

原创 1907_Arm Cortex-M3的基本了解

其实，从之前的M系列的对比表上也是可以看出一些信息的。M4是有DSP的，而M3是没有DSP的。DSP肯定是有自己的指令集的，因此M4肯定有多于M3的指令。我发现Arm Coretex-M3有一个专门的DataSheet，看起来这个的确是被当做了一个设计的产品来对待的。大概看了下，可能左下角的小方块是v6的架构，其他的全都是v7？不知道现在的编译器是否会优先考虑这方面的使用，否则两者的算力或者性能岂不是没有过多的差距？M3的MPU这里描述是可选的，在之前看M系列内核的对比表的时候还以为这个是必然会集成的。

2024-03-01 08:29:06 1007

原创 1905_ARMv7-M的堆栈寄存器

SP寄存器的最低2bit，SP[1:0]在指令集种的规定为：读取的时候为零，写入的时候忽略。为了保证最大的可移植性，也建议在实现ARMv7设计的时候保证这两个bit应该是0或者预留。这里有一个状态位可以设置来判断当前的堆栈使用，而这个寄存器的位是可以通过MRS或者MSR进行读或者写的。ARMv7-M实现了2种堆栈，分别是MSP和PSP。复位的时候默认是MSP，而当前是哪种可以通过CONTROL.SPSEL寄存器的bit来查看。MSP主要是用来处理OS的内核以及异常信息的，而PSP主要是用来处理应用程序的。

2024-03-01 08:27:04 730

原创 1906_ AMBA_高级MCU总线架构

这个也是我最初接触到的一个总线名字，应该是在调试一个国产的MCU的时候对方的技术支持提到了这个名称。它针对先进的异构系统和基于 Arm 的相关 SMP，为设备连接提供单一且统一的接口，以实现最大的互操作性。AMBA CHI 规范将协议层和传输层分开，以允许不同的实现，以在性能、功耗和面积之间提供最佳权衡。在看内核相关的文件的时候看到了AMBA这个缩写，查了一下具体的概念。关于这部分的了解感觉基本到这么多就好了，从当前的内容介绍来看，可能侧重于软件设计的话这些信息的了解深入或者浅一些都是无伤大雅的。

2024-02-25 10:29:11 909

原创 1904_ARM Cortex M系列芯片特性小结

锁步核的支持，也只存在于M7之上，这样很多功能安全的设计要求高的就只能选择M7内核的MCU了。这几个接触过的内核中，只有M4、M33以及M7是有FPU可以选配的，而且只有M7可能选配双精度的支持。DSP的功能支持，在我用过的架构中，M4以及M7是支持的。当然，从普遍规律上来看，大的趋势的确是如此。不过我用过的芯片里面只有M33内核是支持的，而且实际的使用中并没有用到对应的功能。以前整理过一个M0内核的了解资料，这样通过对这个表格的信息的整理，对我之前用过的一部分MCU的内核信息的了解算是又多了一些完善了。

2024-02-25 09:59:48 1010

原创 1903_CoreMark白皮书阅读笔记

如果链表的大小超过了Cache的大小，还可以同时测试内存以及缓存的层级结构的效率。设计采用了常见的数据结构和算法，而且用到的运算都是在运行的过程中计算出来的从而避免编译器优化带来的影响。运行的方法以及报告方式也做了标准化的要求。这么小的内存的需求量在一些低端的嵌入式MCU上都是可以满足的。这个是一个基本的测试结果的展示，涉及到了不同的主频下的表现、不同的编译器版本的表现以及相同的MCU和编译器但是不同编译选项的表现。再看ARM的内核架构介绍的时候看到了不同的内核都测试了一个CoreMark/Mhz的参数。

2024-02-22 08:37:29 708

原创 1902_野火FreeRTOS教程内核在STM32中用到的2个中断PENDSV和SYSTICK

这两个语句的操作实现的功能更是把Systick以及PendSV中断的优先级设置为15，也就是最低。其实，功能分析到此，现在这两个中断的优先级究竟应该设置为多少是合理的暂且还是不明确的。首先看93行，这个是KEIL中的一个伪指令，主要实现的功能是保证汇编代码中的堆栈能够按照8字节对齐。这个地址区从手册中可以查出来是SRAM的区域，这样，这一句实现的作用就是设置了堆栈在RAM区域的位置。再次结合这一个信息，上面的操作有效的部分其实是把这两个字节的高4bit全都设置为了1。这么看，注释写的应该是更加准确一些。

2024-02-20 08:30:23 1058

原创 1901_野火FreeRTOS教程之任务链表以及调度部分阅读

首先是任务就绪链表的初始化，这个继续链表是按照优先级来分的。通过这部分的代码分析看，其实如果是要让自己的系统资源占用更优一些，尽量按照自己真正的需求来配置优先级。接下来的处理，就是创建任务然后把任务关联到对应的链表中。而任务创建所实现的功能，之前已经分析过，主要是做了一个TCB的信息准备。这里有一个任务控制块的参数处理有一点复杂，主要是因为C语言的写法有不同的表达方式。至于MCU内核相关的一些部分的整理以及分档的对应解读，后面单独拆分出来单独看。可以实现同样的效果，具体的运行效果可以从打印的信息看到。

2024-02-20 08:25:58 1024

原创 1900_野火FreeRTOS教程阅读补充材料_AAPCS

比如，有的寄存器是用于传递参数的，有的寄存器测试用来存储变量的。这里的变量是局部变量，后面的资料中看到了进一步的解释。这个说法看起来是不准确的，因为常用的float其实是占用4个字节，double才是8个字节。进程以及函数很多时候概念是统一不拆分的，在这个文档中把这两个词语的更加细致的区分点描述了一下。容器化向量的内容对大多数调用来说是不透明的，唯一明确的规定内容为内存布局与调用接口上不同寄存器间的映射关系。这是返回值的传递方式，基本的原则也是能用寄存器则用寄存器，不能再借助于内存通过指针传递。

2024-02-20 08:20:01 1147

原创 1899_野火FreeRTOS教程阅读笔记_任务创建

堆栈在这个接口中其实主要的处理是做了一个对齐的处理，对齐处理的操作是：根据静态任务创建接口xTaskCreateStatic()中传入的静态创建所分配的存储buffer所指向的内存做一个对齐的处理。这个对齐的要求主要是MCU的架构决定的，这里是按照8个字节来对齐，主要就是考虑了浮点运算时候的一个对齐。书中的例子采用了静态创建任务的方式，这个其实我在自己使用这个OS的时候没用过，我创建任务的时候都用的动态的形式。首先要理解这个栈的处理方式，栈的增长是从上到下的，因此上面的地址会是一个递减的处理过程。

2024-02-08 17:17:52 1326

原创 1898_野火FreeRTOS教程阅读笔记_链表操作

这第一次用到了xItemValue的元素，其实这个元素的数值算是一个元素在链表上的位置的权重信息。新的节点的插入，影响到的是链表中最后一个元素的后继以及当前被插入元素的前驱、后继以及归属属性。具体的操作效果为：新的节点更新自己的前驱和后继，而对等的关联信息则是当前pxIndex所指向的前驱和链表的尾结点。而链表的尾结点在初始化的时候，pxIndex存储的其实是指向链表尾结点Item的指针。因此，这里的这个赋值更新，其实是实现了让这个新的节点指向了链表的尾节点。这个跟预期的效果也是一样的。

2024-02-08 17:16:04 1414

原创 1897_野火FreeRTOS教程阅读笔记_链表

单向链表可以理解为只能够判断自己的后继，无法直接判断自己的前驱的链表设计。对于链表节点的初始化，只是让这个节点与系统中的链表回到一种正交的关系。在插入一个链表的时候，明确这部分从属信息，进而明确前驱以及后继的关系。当然，对于FreeRTOS来说，还有一个更重要的信息需要在节点插入链表的时候明确，那就是所映射的内核管理对象。虽然，不同的人介绍的时候可能选择不同的类比模型，但是无非还是前后台以及OS在原理概念上的差异。这是岔出去的一个话题点。在根节点上，记录了链表的节点数目、遍历所用的指针以及链表的结束节点。

2024-02-08 17:11:10 786

空空如也

空空如也