C语言单链表查找与建立操作详解:从指针原理到实战避坑
1. 为什么单链表操作值得反复打磨单链表这个数据结构几乎每个学C语言的人都会碰到。但我在带新人和看代码的过程中发现一个现象很多人能默写出插入、删除的代码却在实际写查找和建表时频繁翻车。比如查找时忘了处理头节点为空的情况建表时用头插法导致数据顺序反了或者尾插法忘了维护尾指针导致每次插入都要遍历一遍。这些问题的根源不在于语法不熟而在于对单链表的内存模型和指针操作的本质理解不够透彻。单链表的核心就两件事一是每个节点通过指针串联二是头指针是访问整条链的唯一入口。查找和建立这两个操作恰好一个是从入口出发遍历一个是从零开始构建入口把这两个搞明白了单链表的其他操作基本就是举一反三的事。这篇内容我会从实际编码的角度出发把单链表的查找和建立操作拆开揉碎讲清楚。适合已经了解C语言基础语法、但对指针操作还不够有信心的读者也适合想重新梳理链表知识体系的开发者。我会重点讲清楚每一步为什么这么写、常见的坑在哪里、以及实际项目中怎么选择不同的建表方式。2. 单链表查找操作的完整拆解2.1 按值查找从遍历逻辑到边界处理按值查找的需求很直白给定一个目标值在链表中找到第一个存储该值的节点返回它的位置或指针。看起来简单但实际写起来有几个关键决策点。先定义节点结构typedef struct Node { int data; struct Node *next; } Node;查找函数的基本框架是这样的Node* findByValue(Node *head, int target) { Node *p head; while (p ! NULL) { if (p-data target) { return p; } p p-next; } return NULL; }这段代码的逻辑是用一个游标指针p从头节点开始每次比较当前节点的数据域匹配就返回不匹配就移动到下一个节点直到p变成NULL说明找完了也没找到。这里有几个容易出问题的地方。第一循环条件用p ! NULL而不是p-next ! NULL因为最后一个节点本身也需要被检查。我见过有人写成while (p-next ! NULL)结果最后一个节点的数据永远查不到。第二返回值的选择上返回节点指针比返回位置索引更实用因为拿到指针后可以直接对节点做后续操作比如修改数据或删除节点。如果确实需要返回位置索引代码要改成这样int findByValuePos(Node *head, int target) { Node *p head; int pos 1; while (p ! NULL) { if (p-data target) { return pos; } p p-next; pos; } return 0; // 0表示未找到位置从1开始计数 }用0表示未找到是一个约定因为有效位置从1开始。这个约定在实际项目中很常见但一定要在函数注释里写清楚否则调用方可能误以为0是第一个位置。2.2 按位置查找第k个节点怎么找才不出错按位置查找就是找链表中第k个节点。这个操作在插入和删除时经常作为辅助函数使用。代码本身不复杂但边界条件特别多。Node* findByPosition(Node *head, int k) { if (k 1) return NULL; Node *p head; int count 1; while (p ! NULL count k) { p p-next; count; } return p; // 如果k超出链表长度p最终为NULL }这段代码的精妙之处在于循环条件p ! NULL count k。当k大于链表长度时p会先变成NULL循环退出返回NULL。当k合法时循环执行k-1次p正好指向第k个节点。我刚开始写链表的时候经常在这里犯一个错误先遍历计数得到链表长度再判断k是否合法然后再遍历一次找第k个。这样做逻辑上没错但遍历了两次效率低。更好的做法就是上面这种一次遍历边走边判断。还有一个细节值得注意count从1开始还是从0开始。如果从0开始循环条件变成count k-1代码也能工作但可读性差一些。我建议统一用从1开始的计数方式和人类的直觉一致代码审查时不容易看错。2.3 查找操作的性能分析与优化思路单链表的查找时间复杂度是O(n)这是由链表的存储结构决定的。和数组的随机访问O(1)相比链表在查找上确实没有优势。但这不意味着查找操作没有优化空间。一个常见的优化是将最近访问的节点移到链表头部。这个策略基于一个假设如果一个元素被访问了它很可能在不久的将来被再次访问。实现方式是在找到目标节点后把它从原位置摘下来再插入到头部。这样下次查找同一个元素时只需要O(1)的时间。Node* findByValueMoveToFront(Node *head, int target) { if (head NULL || head-data target) return head; Node *prev head; Node *cur head-next; while (cur ! NULL) { if (cur-data target) { prev-next cur-next; cur-next head; return cur; // cur成为新的头节点 } prev cur; cur cur-next; } return head; }这个优化在特定场景下很有效比如实现一个简单的缓存。但要注意它会改变链表的顺序如果业务逻辑依赖顺序就不能用。另一个思路是维护一个访问频率的辅助结构但这已经超出了单链表本身的范围属于更复杂的数据结构设计。对于大多数日常开发场景老老实实用O(n)的遍历查找就够了没必要过度设计。注意查找操作返回指针后调用方使用该指针前应确认链表没有被其他操作修改。在单线程环境下这通常不是问题但在多线程环境中需要额外的同步机制。3. 单链表建立操作头插法与尾插法的选择3.1 头插法的实现细节与适用场景头插法的思路是每次新节点都插入到链表的头部成为新的头节点。代码非常简洁Node* createListHeadInsert(int arr[], int n) { Node *head NULL; for (int i 0; i n; i) { Node *newNode (Node*)malloc(sizeof(Node)); newNode-data arr[i]; newNode-next head; head newNode; } return head; }三行核心代码就完成了插入。newNode的next指向当前的头然后head更新为newNode。整个过程不需要判断链表是否为空也不需要遍历找尾节点。但头插法有一个显著的特点生成的链表顺序和输入顺序相反。如果输入数组是[1, 2, 3, 4, 5]建出来的链表是5-4-3-2-1。这不是bug而是头插法的固有特性。头插法适合什么场景当你需要逆序处理数据时头插法天然就是逆序的不需要额外的反转操作。比如从文件中逐行读取数据要求按相反顺序输出用头插法建表然后直接遍历就行了。另一个场景是当你不关心顺序只关心元素集合时头插法是最快的建表方式。3.2 尾插法的实现与尾指针的维护尾插法要把新节点接到链表末尾保持输入顺序。如果不做优化每次插入都要从头遍历到尾时间复杂度是O(n²)。优化的关键是维护一个尾指针Node* createListTailInsert(int arr[], int n) { Node *head NULL; Node *tail NULL; for (int i 0; i n; i) { Node *newNode (Node*)malloc(sizeof(Node)); newNode-data arr[i]; newNode-next NULL; if (head NULL) { head newNode; tail newNode; } else { tail-next newNode; tail newNode; } } return head; }这段代码里head和tail初始都是NULL。第一个节点插入时head和tail同时指向它。后续节点插入时把tail的next指向新节点然后tail后移到新节点。这样每次插入都是O(1)整体建表是O(n)。我第一次写尾插法时犯过一个错误忘了处理第一个节点的特殊情况直接写tail-next newNode结果tail是NULL导致程序崩溃。后来我总结了一个经验凡是涉及头节点和尾节点的操作第一件事就是判断链表是否为空。还有一种更简洁的写法使用带头节点的链表。头节点是一个不存储有效数据的哨兵节点它的存在让空链表和非空链表的处理逻辑统一了Node* createListWithDummyHead(int arr[], int n) { Node *dummy (Node*)malloc(sizeof(Node)); dummy-next NULL; Node *tail dummy; for (int i 0; i n; i) { Node *newNode (Node*)malloc(sizeof(Node)); newNode-data arr[i]; newNode-next NULL; tail-next newNode; tail newNode; } Node *head dummy-next; free(dummy); return head; }带头节点的写法在插入和删除时特别方便因为不需要单独处理在头部操作的情况。很多经典教材和开源项目都采用这种设计。3.3 两种建表方式的对比与选型建议对比维度头插法尾插法时间复杂度O(n)O(n)维护尾指针空间复杂度O(1)额外空间O(1)额外空间生成顺序与输入相反与输入相同代码复杂度极简稍复杂需处理空表适用场景逆序需求、不关心顺序保持顺序、队列模拟选型的核心判断标准就一条你是否需要保持输入顺序。需要就用尾插法不需要就用头插法。不要为了代码简洁而在需要顺序的场景强行用头插法然后再反转那样反而多了一次O(n)的操作。另外如果建表后还需要频繁在尾部插入那维护尾指针就是必须的。但如果建表后主要在头部操作尾指针反而成了维护负担每次头部插入后如果恰好插在尾部还需要更新尾指针。所以数据结构的辅助指针要根据实际访问模式来决定。4. 从零手写完整可运行的示例代码4.1 代码组织与函数声明把查找和建表的操作整合到一个完整的程序中方便直接编译运行。先看头文件和函数声明#include stdio.h #include stdlib.h typedef struct Node { int data; struct Node *next; } Node; Node* createListTailInsert(int arr[], int n); Node* findByValue(Node *head, int target); int findByValuePos(Node *head, int target); Node* findByPosition(Node *head, int k); void printList(Node *head); void freeList(Node *head);函数声明放在前面主函数放在后面这是C语言的标准组织方式。每个函数只做一件事职责单一方便单独测试和调试。4.2 主函数与测试用例设计int main() { int arr[] {10, 20, 30, 40, 50}; int n sizeof(arr) / sizeof(arr[0]); Node *head createListTailInsert(arr, n); printf(链表内容: ); printList(head); // 测试按值查找 Node *found findByValue(head, 30); if (found ! NULL) { printf(找到值30节点地址: %p\n, (void*)found); } else { printf(未找到值30\n); } // 测试按位置查找 Node *posNode findByPosition(head, 3); if (posNode ! NULL) { printf(第3个节点的值: %d\n, posNode-data); } // 测试查找不存在的值 found findByValue(head, 99); printf(查找99的结果: %s\n, found NULL ? 未找到 : 找到了); // 测试越界位置 posNode findByPosition(head, 10); printf(查找第10个节点的结果: %s\n, posNode NULL ? 越界 : 找到了); freeList(head); return 0; }测试用例覆盖了正常查找、边界查找不存在的值、越界位置这些情况。实际开发中我建议每写一个链表函数就立刻写一个测试用例验证不要等所有函数写完再统一测试。链表操作涉及大量指针一旦出错很难定位是哪个函数的问题。4.3 辅助函数的实现void printList(Node *head) { Node *p head; while (p ! NULL) { printf(%d, p-data); if (p-next ! NULL) printf( - ); p p-next; } printf(\n); } void freeList(Node *head) { Node *p head; while (p ! NULL) { Node *temp p; p p-next; free(temp); } }printList用于调试输出格式是10 - 20 - 30 - 40 - 50。freeList用于释放内存注意先用temp保存当前节点p后移之后再free(temp)顺序不能反。如果先free(p)再访问p-next就是访问已释放的内存属于未定义行为。提示在开发阶段可以在freeList中把free掉的指针置为NULL虽然对局部变量temp来说意义不大但养成这个习惯对调试有帮助。5. 那些年我踩过的指针坑5.1 内存泄漏malloc了但没free单链表最常见的内存问题就是泄漏。每次malloc创建一个节点就必须在某个时刻free它。我见过不少代码建表、使用都没问题但程序结束时没有释放链表导致内存泄漏。在短生命周期的小程序中这不算大问题但在长时间运行的服务中累积的泄漏会耗尽内存。更隐蔽的泄漏发生在删除节点时。比如删除一个节点正确的做法是先用临时指针保存要删除的节点调整前驱的next指针然后再free临时指针。如果直接free再调整指针就会丢失后续节点的地址造成链表断裂和内存泄漏。// 正确的删除方式 Node* deleteNode(Node *head, int target) { if (head NULL) return NULL; if (head-data target) { Node *temp head; head head-next; free(temp); return head; } Node *prev head; while (prev-next ! NULL prev-next-data ! target) { prev prev-next; } if (prev-next ! NULL) { Node *temp prev-next; prev-next temp-next; free(temp); } return head; }5.2 野指针free之后还在用野指针是另一个高频问题。free一个节点后该节点的内存已经归还给系统但指针变量本身还保存着原来的地址。如果后续代码不小心通过这个指针访问内存行为是不可预测的。Node *p head; free(p); // 此时p是野指针 p-data 10; // 未定义行为可能崩溃也可能悄悄改掉别的数据防御性编程的做法是free之后立刻把指针置为NULLfree(p); p NULL;这样后续如果误用p程序会立即崩溃在NULL解引用上而不是产生难以追踪的数据损坏。崩溃比静默错误好排查得多。5.3 头指针丢失链表建好了但找不到入口头指针是访问链表的唯一入口一旦丢失整条链表就变成了无法访问的内存垃圾。头指针丢失的常见场景是在遍历过程中不小心修改了head// 错误写法 while (head ! NULL) { printf(%d , head-data); head head-next; // head被修改了 } // 此时head已经是NULL链表入口丢失正确的做法是用一个临时指针来遍历Node *p head; while (p ! NULL) { printf(%d , p-data); p p-next; } // head保持不变这个坑我踩过不止一次特别是在调试时随手写遍历代码忘了保护head。后来我养成了一个习惯任何需要遍历链表的函数第一行就定义临时指针Node *p head;后续所有操作都用p绝不碰head。6. 查找与建表在实际场景中的组合应用6.1 用链表实现简单的学生成绩管理假设需要管理一组学生成绩支持按学号查找和按录入顺序展示。这就是尾插法建表加按值查找的典型组合。typedef struct Student { int id; int score; struct Student *next; } Student; Student* addStudent(Student *head, int id, int score) { Student *newNode (Student*)malloc(sizeof(Student)); newNode-id id; newNode-score score; newNode-next NULL; if (head NULL) return newNode; Student *p head; while (p-next ! NULL) p p-next; p-next newNode; return head; } Student* findStudent(Student *head, int id) { Student *p head; while (p ! NULL) { if (p-id id) return p; p p-next; } return NULL; }这个例子里addStudent每次都要遍历到尾部时间复杂度O(n)。如果学生数量很大且频繁添加就应该维护一个尾指针。但在学生数量不多比如一个班几十人的场景下O(n)的遍历完全可以接受代码简洁更重要。6.2 从文件读取数据建表并按条件查找实际项目中数据往往来自文件。用尾插法保持文件中的原始顺序然后用查找函数筛选满足条件的记录。Node* loadFromFile(const char *filename) { FILE *fp fopen(filename, r); if (fp NULL) return NULL; Node *head NULL, *tail NULL; int value; while (fscanf(fp, %d, value) 1) { Node *newNode (Node*)malloc(sizeof(Node)); newNode-data value; newNode-next NULL; if (head NULL) { head newNode; tail newNode; } else { tail-next newNode; tail newNode; } } fclose(fp); return head; }这段代码里fscanf的返回值判断很重要。当文件读完或格式不匹配时fscanf返回非1的值循环退出。如果忘了判断返回值可能会把无效数据读入链表。6.3 性能考量什么时候不该用单链表单链表的查找是O(n)这是它的固有短板。如果你的应用场景是频繁查找、很少插入删除那数组或哈希表是更好的选择。数组支持O(1)的随机访问哈希表平均O(1)的查找。单链表的优势在于频繁在头部插入删除和不需要连续内存。比如实现一个栈用单链表头插法push、头部删除pop都是O(1)。或者内存碎片化严重的嵌入式环境中链表不需要一块连续的大内存更容易分配成功。选择数据结构时先分析操作的频率分布哪种操作最多对时间复杂度要求是什么内存是否受限把这些想清楚再动手写代码比写完发现性能不达标再重构要省事得多。7. 调试单链表的实用技巧7.1 用打印语句追踪指针变化链表调试最有效的方法就是在关键位置打印指针地址和节点数据。比如在插入操作中printf(插入前: head%p, tail%p\n, (void*)head, (void*)tail); // 插入操作 printf(插入后: head%p, tail%p, newNode%p\n, (void*)head, (void*)tail, (void*)newNode);通过对比插入前后的指针值可以快速判断指针是否正确更新。如果head在插入后变了但你不期望它变那就说明代码有问题。7.2 画图辅助理解指针指向纸上画图是理解链表操作最直观的方式。每写一个操作先画出操作前的链表状态然后一步步画出指针的变化过程。比如头插法画出来就是新节点的next指向原head然后head指向新节点。画一遍图代码自然就写出来了。我到现在遇到复杂的链表操作比如反转、合并、找环还是会先在纸上画图理清思路再写代码。这个方法看起来笨但比在脑子里空想要可靠得多。7.3 使用断言检查不变量在函数的关键位置加入断言检查链表的不变量是否成立#include assert.h // 在函数返回前检查 assert(head NULL || head-data 0); // 假设数据非负断言在Debug版本中生效Release版本中会被移除不影响性能。对于链表这种指针操作密集的代码断言可以帮助在开发阶段尽早发现逻辑错误。8. 从单链表到更复杂结构的延伸单链表的查找和建表是基础中的基础把这个搞扎实了后续学习双向链表、循环链表、链式栈、链式队列都会轻松很多。双向链表无非是多维护一个prev指针建表时多一步设置prev查找时可以从两个方向进行。循环链表就是把尾节点的next指向头节点遍历时需要判断是否回到起点。我的建议是不要急着学更复杂的数据结构先把单链表的每个操作都手写三遍以上直到不看参考代码也能一气呵成地写出来。写完之后再想想如果数据域不是int而是结构体代码需要改哪里如果链表很长递归遍历会不会栈溢出如果要在多线程环境中使用需要加什么保护这些问题的答案比单纯记住代码本身有价值得多。我在实际项目中用链表的频率并不高但链表训练出来的指针操作能力和内存管理意识在写树、图、哈希表时都在发挥作用。基础打牢了上层建筑才稳。

相关新闻

openEuler 20.03 yum仓库配置指南:解决无可用仓库报错

openEuler 20.03 yum仓库配置指南:解决无可用仓库报错

1. 问题背景与核心需求拆解1.1 这个报错到底在说什么如果你刚装完 openEuler release 20.03,兴冲冲敲下yum install想装个软件,结果迎面撞上这么一行:Error: There are no enabled repositories in "/etc/yum.repos.d", "/etc…

2026/10/17 22:45:43 阅读更多 →
前端AES加密从入门到实践:模式选型、密钥管理与代码实现

前端AES加密从入门到实践:模式选型、密钥管理与代码实现

前端AES加密这事儿,我几乎每年都要在团队内部讲一轮。原因很简单:只要你的系统里有登录功能,就一定绕不开一个问题——用户在浏览器里输入的密码,到底怎么传给后端才不那么“裸奔”。我自己早年就踩过坑:当时做了一个内…

2026/10/17 22:45:43 阅读更多 →
pygame音乐播放器第二版:状态机与进度同步实战

pygame音乐播放器第二版:状态机与进度同步实战

1. 从“能响就行”到“好用顺手”:音乐播放器第二版到底在解决什么问题很多人第一次用 pygame 做音乐播放器,跑通pygame.mixer.music.load()加play()之后就觉得大功告成了。我当初也是这么想的,结果真把东西拿给朋友用,十分钟就被…

2026/10/17 22:45:43 阅读更多 →

最新新闻

STM32F1与陶晶池USART HMI串口屏:从接线到DMA多指令刷屏实战

STM32F1与陶晶池USART HMI串口屏:从接线到DMA多指令刷屏实战

简介:面向嵌入式开发者的陶晶池USART HMI串口屏与STM32F1通信详解资源包,聚焦STM32F103与串口屏的异步串行通信实现。内容覆盖USART波特率计算与USART_BRR寄存器配置、数据帧格式设定、TXE/RXNE标志处理及中断收发机制,并附有完整通信程序示例…

2026/10/19 0:59:10 阅读更多 →
Postman接口测试从入门到自动化实战指南

Postman接口测试从入门到自动化实战指南

1. 准备工作:安装、界面与第一个请求1.1 为什么是Postman,而不是其他工具先聊点实际的。我在测试岗摸爬滚手这几年,见过不少团队在接口测试工具上的纠结史:有人用命令行curl一把梭,有人用浏览器开发者工具手动拼请求&a…

2026/10/19 0:58:09 阅读更多 →
Playwright企业级自动化:从脚本到高并发稳定平台的落地实践

Playwright企业级自动化:从脚本到高并发稳定平台的落地实践

Playwright 这名字在自动化测试圈子里火了好几年了,但大多数团队的用法还停留在“写几个脚本跑回归”的阶段。真正把它当成企业级基础设施来搭、要扛住每天几百上千次任务调度的团队,其实不多。这篇文章写的就是后者:从选型到架构设计&#x…

2026/10/19 0:58:09 阅读更多 →
OFDM信道估计算法BER性能实测对比:LS/LMMSE/DCT五种方案选型指南

OFDM信道估计算法BER性能实测对比:LS/LMMSE/DCT五种方案选型指南

简介:本资源是一份面向通信工程专业本科生、研究生及无线通信算法研究者的OFDM信道估计仿真实验包,聚焦于误码率(BER)性能对比这一核心问题,系统验证LS、LMMSE、LR-MMSE、DCT与DFT五种主流信道估计算法在不同信噪比与多…

2026/10/19 0:58:09 阅读更多 →
IEC 61131标准详解:PLC编程语言、软件模型与实战排查

IEC 61131标准详解:PLC编程语言、软件模型与实战排查

用IEC 61131这套标准串起PLC编程这件事,是很多工程师绕了远路之后才意识到必须做的事。我见过太多人只会用某个品牌环境的工具栏点来点去,换一个牌子的PLC就抓瞎;也见过有经验的老法师,能把梯形图画得像天书一样漂亮,但…

2026/10/19 0:58:09 阅读更多 →
从数据模型到通信整合:DeskcommCRM自研实战

从数据模型到通信整合:DeskcommCRM自研实战

1. 为什么会有 DeskcommCRM:一个绕不开的客户管理困局事情得从一次非常尴尬的客户投诉说起。当时我们团队七八个人,客户信息散在三个地方:销售个人的微信聊天记录、一个共享Excel表、还有客服同事脑袋里的记忆。有位客户在月初问过报价&#…

2026/10/19 0:58:09 阅读更多 →

日新闻

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

简介:本资源为电源技术方向的学术研究文档,聚焦介质阻挡放电型臭氧发生器电源的频率跟踪型PWM控制策略,面向电力电子、高压电源及臭氧应用领域的科研人员与工程技术人员。针对负载呈容性、等效电容随外加电压升高而增大、谐振频率随之漂移的难…

2026/10/19 0:00:47 阅读更多 →
Vibe Coding 遇上 TaoToken:把开发者思维圣殿的灵感流接入统一 Key 通道

Vibe Coding 遇上 TaoToken:把开发者思维圣殿的灵感流接入统一 Key 通道

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/19 0:00:47 阅读更多 →
HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

【免费下载链接】HundredCV-Chat 项目地址: https://ai.gitcode.com/hf_mirrors/Jax-dan/HundredCV-Chat 点击查看 免费下载 HundredCV-Chat 是一个由 100 位青年简历数据开发而来的中文多轮对话数据集,共包含 24,750 组日常闲聊对话和 4,871 个话题标签…

2026/10/19 0:00:47 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/18 0:00:55 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/18 0:00:55 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/18 0:00:55 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/18 0:55:02 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/17 17:22:31 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/18 12:16:16 阅读更多 →