Linux系统编程：目录操作与用户权限的底层原理与实战-北京尧图网络

1. 写在前面为什么目录和用户操作是系统编程的“地基”我做了十来年Linux服务端开发带过不少新人也面试过很多人有个感触特别深很多人写业务代码很溜但一碰到“目录操作”和“用户/权限体系”就露怯。不是他们不会调API而是不清楚这些API背后操作系统到底做了什么。比如mkdir()明明返回成功目录却没创建出来比如setuid()调用成功了但程序权限却没降下来比如遍历目录时突然碰到死循环——这些坑教科书上不会详细讲但真实项目里天天见。这篇文章我把Linux系统编程里“目录”和“用户操作”这两大块内容做个系统性的梳理。不是照着man page念一遍而是从“操作系统到底怎么想”的角度把底层原理、常用API的坑、实战代码、排查思路全部串起来。适合正在学Linux编程的在校生、刚转服务端开发的工程师以及那些写了好几年代码但一直没时间系统补这块知识的同学。我尽量做到原理讲透为什么必须这样设计、代码能跑直接复制去验证、坑点标清哪些地方容易翻车。全程不贴几百行大段代码但关键函数、关键参数一定会给全方便你本地实测。2. 目录操作不只是一个“文件夹”那么简单2.1 目录的本质是映射表不是容器很多人对目录的理解停留在Windows时代——文件夹是个“放文件的盒子”。但在Linux内核里目录压根不是容器它本质上是一个映射表记录的是“文件名 → inode编号”的对应关系。这个理解不到位后面很多问题都会想不通。举个例子你执行ls /etc的时候内核做的事情不是“打开/etc文件夹看看里面有什么”而是找到/etc目录的inode读取这个inode对应的数据块里面全是dentry结构即目录项把每个dentry里的文件名和inode号输出出来dentry结构体里存的关键字段就两个文件名和inode编号。所以目录的“大小”不是看里面文件总大小而是看它有多少个目录项。这也解释了一个经典现象一个空目录的大小通常是4096字节一个块而不是0。理解了这个再去看link()系统调用的实现就顺了——所谓的“硬链接”本质就是在某个目录的映射表里新增一行“文件名→同一个inode编号”。所以硬链接不能跨文件系统因为不同文件系统的inode编号是各自独立的你在A文件系统里建一个条目指向B文件系统的inode号那就乱套了。2.2 目录操作的核心API与隐藏陷阱目录相关的系统调用最核心的就那几个mkdir()、rmdir()、chdir()、getcwd()、opendir()/readdir()、rename()。每个我都挑重点讲包括那些man page里不容易注意到的细节。open()打开目录的特殊标志很多人不知道open()也能用来打开目录但要加两个关键标志int fd open(/etc, O_RDONLY | O_DIRECTORY);O_DIRECTORY告诉内核我要求打开的是一个目录如果你给的不是目录直接返回ENOTDIR。这个标志在写递归遍历程序时很有用——可以避免open()那个路径实际上是个普通文件导致后面读出来的内容全是乱码垃圾。还有一个我经常用的组合是O_DIRECTORY | O_NOFOLLOW禁止跟随符号链接防止别人把一个目录替换成指向敏感位置的软链这在写安全工具时是必备的。mkdir()不会递归创建这是个天坑mkdir(/a/b/c, 0755)只有在/a/b已经存在的前提下才能成功。如果/a/b不存在直接返回ENOENT。很多新手在这里懵掉以为系统会自动把中间层目录建好。PHP里的mkdir($path, 0755, true)支持递归创建那是PHP帮你循环调了系统调用内核本身不提供这种功能。实际项目里自己封装一个递归函数很常见int mkdir_p(const char *path, mode_t mode) { char tmp[PATH_MAX]; size_t len strlen(path); if (len 0 || len PATH_MAX) return -1; memcpy(tmp, path, len 1); // 逐个尝试创建每一级目录 for (char *p tmp 1; *p; p) { if (*p /) { *p \0; if (mkdir(tmp, mode) ! 0 errno ! EEXIST) { *p /; return -1; } *p /; } } if (mkdir(tmp, mode) ! 0 errno ! EEXIST) { return -1; } return 0; }注意这里有个容易被忽略的细节mkdir()返回EEXIST不一定代表目录已经存在也可能是个同名的普通文件。所以严格来说遇到EEXIST之后还应该用stat()确认一下目标类型。但在大部分业务场景下目录已经存在就直接放行问题不大。如果写的是严谨的系统工具这一步验证不能省。rmdir()只能删空目录rmdir(/tmp/foo)只有当/tmp/foo里没有任何条目时才能成功不然返回ENOTEMPTY。那要删除非空目录怎么办只能自己递归删除或者调用nftw()文件树遍历函数。这个问题我在第三大部分会展开讲因为“递归删除目录”是系统编程面试的经典手写题。chdir()与getcwd()的协作与坑chdir()只接受路径字符串如果你已经用open()拿到目录的文件描述符更推荐用fchdir(fd)可以避免路径检查时的竞态条件TOCTOUTime Of Check To Time Of Use。getcwd()有两个坑值得说第一个是缓冲区大小。PATH_MAX虽然定义在limits.h里但Linux路径理论上没有硬上限你可以通过mount把路径拼得很长。稳妥的办法是传NULL作为第一个参数让glibc自己用malloc()分配char *cwd getcwd(NULL, 0); // 用完必须 free(cwd)第二个是“当前工作目录被删除”的情况。你在某个目录里chdir()进去然后别的进程把这个目录删了你再执行getcwd()就会失败errno是ENOENT。共享存储系统上这种场景很常见一个进程在挂载点里切换了目录挂载点被卸载了getcwd()也会失败。3. 目录遍历与递归删除原理、代码与边界处理3.1 手写递归遍历每个C程序员都应该过关目录遍历在Linux系统编程里实在太常用了找文件、统计大小、同步备份、日志清理底层全是目录遍历。最正统的写法是用opendir()readdir()lstat()void walk_dir(const char *path) { DIR *dir opendir(path); if (!dir) { perror(opendir); return; } struct dirent *entry; while ((entry readdir(dir)) ! NULL) { // 跳过 . 和 .. if (strcmp(entry-d_name, .) 0 || strcmp(entry-d_name, ..) 0) { continue; } char fullpath[PATH_MAX]; snprintf(fullpath, sizeof(fullpath), %s/%s, path, entry-d_name); struct stat st; if (lstat(fullpath, st) ! 0) { perror(lstat); continue; } if (S_ISDIR(st.st_mode)) { walk_dir(fullpath); // 递归进入子目录 } else { printf(%s\n, fullpath); } } closedir(dir); }这里有个关键点判断文件类型时必须用lstat()而不是stat()。区别在于stat()会跟随符号链接如果目录里有个软链接指向另一个目录stat()会把软链接解析成目标目录然后你的递归就会走进一条你根本没打算走的路径。用lstat()得到的是软链接本身的属性S_ISLNK(st.st_mode)为真你就能把它当普通文件处理而不是当成目录钻进去。3.2 符号链接死循环遍历程序最容易翻车的地方只要你在Linux上写过目录遍历程序几乎一定遇到过符号链接导致的死循环。场景是这样的/tmp/a/link_b是个软链接指向/tmp/b而/tmp/b/link_a又指回/tmp/a。如果你用stat()而不是lstat()判断类型程序会在这个循环里无限递归最终栈溢出崩溃。有两种常见的解决方案第一种是深度限制简单粗暴但有效void walk_dir_depth(const char *path, int depth) { if (depth MAX_DEPTH) return; // ... 逻辑同上递归时传入 depth1 }第二种是跟踪已经访问过的目录inode用哈希表存(st_dev, st_ino)遇到重复的就跳过。这个方法更严谨能精确判断“这个目录是不是已经来过”而不是靠最大深度近似拦截。我个人的建议是两种都上深度限制保底inode去重做精确判断。生产环境里一个恶意或误操作的软链接就能让遍历程序CPU飙到100%这种情况下多一道保险就少一次半夜被叫醒的体验。3.3 递归删除目录树面试必考的手写题删除非空目录树原理就是“后序遍历”先删空目录里的所有条目最后删除目录本身。难点在于文件名可能是目录、普通文件、软链接也可能是设备文件、socket。正确做法是拿到文件类型后分类处理int remove_recursive(const char *path) { struct stat st; if (lstat(path, st) ! 0) { return -1; } // 先处理内容再处理自己 if (S_ISDIR(st.st_mode)) { DIR *dir opendir(path); if (!dir) return -1; struct dirent *entry; while ((entry readdir(dir)) ! NULL) { if (strcmp(entry-d_name, .) 0 || strcmp(entry-d_name, ..) 0) { continue; } char fullpath[PATH_MAX]; snprintf(fullpath, sizeof(fullpath), %s/%s, path, entry-d_name); remove_recursive(fullpath); } closedir(dir); return rmdir(path); } // 普通文件、软链接、设备等统一用 unlink return unlink(path); }这里我刻意用了lstat判断原因和遍历时一样——如果目标是软链接直接unlink()删掉链接本身绝对不能顺着软链接去删除它指向的真实文件。在写这类工具时有一个血泪教训曾经有一次清理临时目录因为对软链接调用了stat()再递归删除结果把别的服务正在使用的目录树整个删掉了。还有个边界情况得提一嘴readdir()返回的d_type字段在某些文件系统如网络文件系统上可能是DT_UNKNOWN此时不能直接信赖它必须用lstat()兜底。这也是为什么我上面的代码干脆直接走lstat()省得踩文件系统差异的坑。4. 用户操作UID、GID 与权限体系的底层逻辑4.1 内核里没有“用户名”只有数字ID学Linux系统编程第一件事就是转变思维在操作系统内核层面用户名是不存在的。内核只认识UID用户ID和GID组ID。你看到ls -l输出里的root、www-data这种名字那只是getpwuid()从/etc/passwd里查表翻译出来的结果。/etc/passwd每行七个字段冒号分隔root:x:0:0:root:/root:/bin/bash www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin按顺序分别是用户名、密码占位符真实密码在/etc/shadow、UID、GID、用户说明、家目录、登录Shell。有个超经典的坑很多人误以为“UID为0的用户一定是root”。严格讲不对。Linux内核判断权限的依据是UID是否为0不是用户名是否为root。如果你手动把某个用户的UID改成0那它就拥有root级别的权限即使它的用户名叫test或nobody。反过来如果把root的UID改成1000系统里就没有真正意义上的特权用户了这会直接把系统搞崩别试。所以安全审计时要记住检查特权用户查的是UID 0不是用户名root。4.2 用户信息操作API从查询到校验写程序时经常需要查用户信息三个函数是主力getpwuid()按UID查、getpwnam()按用户名查、getgrgid()按GID查组信息。#include sys/types.h #include pwd.h struct passwd *pw getpwnam(www-data); if (pw) { printf(UID: %d\n, pw-pw_uid); printf(GID: %d\n, pw-pw_gid); printf(Home: %s\n, pw-pw_dir); printf(Shell: %s\n, pw-pw_shell); }注意getpwnam()和getpwuid()返回的指针指向静态存储区下一次调用会覆盖上一次的结果。多线程程序必须用getpwnam_r()这类带_r后缀的线程安全版本struct passwd pwd; struct passwd *result; char buf[1024]; int ret getpwnam_r(www-data, pwd, buf, sizeof(buf), result); if (ret 0 result ! NULL) { // 成功拿到用户信息 }_r版本的核心思路是调用者自己提供缓冲区避免静态存储带来的并发覆盖问题。这个细节在面试里经常考实际项目里跑多线程服务时踩过一次坑后就再也不敢用不带_r的版本了。4.3 身份管理getuid、geteuid与“三权分立”Linux进程和用户相关的ID不止一个至少有真实UIDreal UID进程启动者的身份getuid()返回有效UIDeffective UID权限判断用的身份geteuid()返回保存的UIDsaved UID用于在特权和非特权身份之间来回切换通过setuid()恢复到原来的特权刚开始接触这块的人经常会问为什么搞这么复杂两个还不够吗答案是为了支持“临时降权事后恢复”。举个经典例子一个程序以root身份启动因为需要绑定80端口但实际处理业务逻辑时不希望用root权限。常规做法是启动后立刻降权到普通用户。但万一某段代码在降权后还需要临时执行某个只有root能做的操作比如重启后重新绑定端口就需要saved UID保留原始身份然后临时切换回去。// 启动时是 root uid_t original_uid geteuid(); // 保存到 saved uid // 降权到 nobody struct passwd *pw getpwnam(nobody); setuid(pw-pw_uid); // 现在有效UID变成 nobody // 需要特权时 seteuid(original_uid); // 切回rootsaved uid 允许 // 执行特权操作 setuid(pw-pw_uid); // 再次降权这个机制的设计非常巧妙但也是绕很多人的点。建议自己画一张图一行进程三个身份标注谁来决定文件访问权限有效UID谁在setuid()时能恢复原状saved UID。5. 实战场景提权、降权与权限校验的完整方案5.1 守护进程如何正确降权服务端开发里最常见的需求bind()到80端口需要root但业务逻辑绝不希望以root运行。我见过很多项目在这块的写法是直接setuid()完事但有几个坑经常栽第一个坑降权前没有初始化好所有资源。setuid()之后进程就失去root权限了。如果你降权之前没打开日志文件、没创建PID文件、没绑定业务端口之后再操作就会因为权限不足失败。所以标准流程是创建socket → bind → listen → 打开日志 → 全部就绪后再降权。第二个坑只调setuid()没调setgid()。权限判断既看UID也看GID。如果只改用户不改组进程可能仍然处于一个特权组里。正确姿势是先把GID切掉再切UIDstruct passwd *pw getpwnam(nobody); if (!pw) exit(1); // 先初始化所有需要特权的资源 // 然后开始降权 if (setgroups(0, NULL) ! 0) { // 清空附加组列表这一步很多人漏 perror(setgroups); exit(1); } if (setgid(pw-pw_gid) ! 0) { perror(setgid); exit(1); } if (setuid(pw-pw_uid) ! 0) { perror(setuid); exit(1); }第三个坑最隐蔽setuid()在多线程程序里的行为。Linux的setuid()在多线程环境下作用于进程内所有线程但glibc内部有锁调用时机不对可能死锁或行为异常。最佳实践是在启动早期、还没创建业务线程之前完成降权。如果迫不得已要在多线程运行后降权必须用seteuid()而不是setuid()并且要格外谨慎。5.2 权限校验别用access用euid业务代码里经常需要判断“当前用户有没有权限做某件事”。新手最容易写错的代码是if (access(/etc/config.ini, R_OK) 0) { // 认为可以读 }access()系统调用检查的是真实UID的权限而程序真正读写文件时内核检查的是有效UID的权限。如果程序是SUID程序设置了SetUID位默认以属主身份运行access()得出的结论和实际操作的结果可能完全不同。举个具体场景一个SUID root程序希望判断“调用者真实用户能否读某个文件”。access()查的是调用者的权限刚好符合需求。但如果这个程序本身要用root身份去读配置文件就不该用access()应该直接open()然后检查返回值——通过errno是EACCES还是ENOENT来判断权限不足和文件不存在。老练的做法是别做权限预判直接操作根据返回值处理。这样既省掉一次多余的权限检查也避免因TOCTOU竞态导致判断结果和实际操作脱节。5.3 SUID程序的安全边界setuid的权限逃逸风险SUID程序是Linux系统里一个危险又必要的存在。passwd、mount、ping这些都需要root权限但执行者是普通用户所以它们都被设置了SUID位属主root模式-rwsr-xr-x。SUID机制的本质是普通用户执行这个程序时进程的有效UID切换为文件属主的UID通常是0。这就带来一个巨大的安全挑战——如果程序写得有漏洞普通用户就能利用它干root才能干的事。在系统编程层面SUID程序必须遵守几条铁律环境变量不可信。PATH、LD_PRELOAD、LD_LIBRARY_PATH这些都可能被恶意构造。所以SUID程序启动早期应该重置环境变量用绝对路径调用外部程序。规范所有输入路径。前面提过的O_NOFOLLOW标志对于SUID程序处理目录内文件时必备——防止用户构造一个软链接指向/etc/shadow。打开的文件描述符要防泄露。避免低权限用户通过/proc/self/fd访问SUID程序已打开的特权文件。降权要彻底。setuid()不仅要把有效UID降下来还要确认进程没有残留附加组权限getgroups()查看。5.4 实战代码一个目录隔离的临时提权方案最后一个实战场景把目录和用户操作合在一起。假设你要写一个系统管理工具需要在指定目录里创建文件但目录的属主是另一个用户。方案是先降级到该目录属主的身份操作完后再恢复前提是进程启动时是root。// 在完整代码中伪代码如下 uid_t owner_uid 1001; // 目标目录属主的UID // 切到目标用户身份 if (seteuid(owner_uid) ! 0) { perror(seteuid); exit(1); } // 以目标用户身份创建目录 if (mkdir(/data/app/cache, 0755) ! 0 errno ! EEXIST) { perror(mkdir); // 别忘了恢复身份 seteuid(0); exit(1); } // 操作完成恢复root if (seteuid(0) ! 0) { perror(seteuid restore); exit(1); }这种“临时换身份”的手法在安装程序、包管理器、初始化脚本里非常常见。关键点是恢复身份后要检查返回值如果恢复失败程序后续还以低权限运行但代码却假设自己依然有root权限可能引发比权限不足更严重的逻辑错误——比如误报“操作成功”。6. 常见问题与排查技巧实录6.1 “目录操作失败”的errno速查目录操作出现问题时第一步永远是查errno。我把最常见的几个错误码和对应的场景整理成一张速查表errno含义典型触发场景ENOENT路径不存在或路径中的某一级分量不存在mkdir()递归创建时父目录缺失chdir()路径输错EACCES权限不足对没有x权限的目录执行opendir()对没有w权限的目录执行mkdir()ENOTDIR路径中某分量不是目录open()时加了O_DIRECTORY但目标不是目录chdir()指向了普通文件ENOTEMPTY目录非空无法删除rmdir()删除非空目录ELOOP符号链接层数过多遍历时没处理软链接陷入循环或路径中软链接链太长ENAMETOOLONG路径名太长拼接路径时没有检查长度超过文件系统单路径上限EMFILE进程打开文件描述符太多opendir()后没closedir()在循环里泄漏fd排查建议在代码里打印错误时别只打印strerror(errno)把完整的操作路径也打出来。我见过太多日志只写“permission denied”却不写“哪个路径没权限”排查效率极低。正确姿势char path[PATH_MAX]; // ... 填充 path if (mkdir(path, 0755) ! 0) { fprintf(stderr, mkdir failed: %s (path%s)\n, strerror(errno), path); return -1; }6.2 排查实例一readdir后忘记closedir的fd泄漏有段时间我们一个配置文件扫描程序运行几天后就会卡死strace一看全是EMFILE。原因就是遍历目录时递归函数在进入子目录前忘了closedir()当前目录的DIR指针。虽然DIR是用户态封装但它底层持有文件描述符进程的fd数量是有限的默认1024ulimit -n可查深层嵌套的目录树几百层就能耗尽fd。排查方法很简单运行程序另开终端执行ls /proc/pid/fd | wc -l如果持续增长基本可以断定fd泄漏。配合lsof -p pid能看到哪个路径的fd没释放。这个问题的修复就是“每一次opendir()必须有配对的closedir()”最好用RAII风格封装或者集中在递归函数里保证出口单一。6.3 排查实例二getpwuid返回空指针写用户管理工具时调用getpwuid(1001)返回了NULL但/etc/passwd里明明有UID 1001的用户。查了很久发现问题是程序在chroot()环境里运行/etc/passwd是chroot之后的文件和宿主机的不是同一个。这个场景提醒我们用户数据库可能不是系统全局的。容器环境、chroot环境、NIS/LDAP环境里getpwuid()查询的数据源可能完全不同。排查用户相关问题时先确认进程所在的“用户信息视图”是哪个。容器里常见的useradd工具自带一套用户库和宿主机是隔离开的。另一个getpwuid()返回空指针的常见原因是UID超过/etc/passwd的解析范围例如程序是32位编译的UID大于INT_MAX。这个在现代64位环境下少见但在嵌入式交叉编译时要注意。6.4 排查实例三setuid调用成功但权限没有变化线上有个服务启动时root身份调用setuid()降权日志显示调用成功但进程还能写root拥有的文件。查了半天才发现程序调用的是seteuid()降权时改成普通用户的euid但真实UID还是0。某些权限检查比如access()是看真实UID的所以看起来权限没变。这里引出一个原则降权时弄清setuid()、seteuid()、setreuid()的区别setuid()如果是root调用三个UID一起设置真实、有效、保存seteuid()只设置有效UID适合临时切换setreuid()允许单独设置真实和有效UID最灵活对于“彻底降权永不恢复”的需求必须用setuid()或setresuid()把三值都改掉而不是seteuid()。另外Linux对setuid()还有个特殊规则非root进程如果调用setuid()只能把有效UID切换为真实UID或保存的UID不能切到任意值。所以普通用户没法通过setuid(0)提权这层保护是内核级的。6.5 排查实例四目录遍历程序CPU 100%一个后台日志清理程序固定每天凌晨扫描一个大目录树某次上线后CPU直接打满top看是我写的进程。strace一抓发现它反复在readdir和lstat之间循环路径越来越深——典型的软链接死循环。修复方案就是我前面说的lstat()判断文件类型记录已访问的(st_dev, st_ino)哈希表。加了这两层后同目录再也没出现过CPU打满的情况。我遇到过的另一个CPU 100%原因是目录树里面有海量小文件百万级而遍历时对每个文件都做了一次snprintf()拼接完整路径再lstat()。单次调用开销不大但百万次扫描就成了瓶颈。优化方向是尽量复用打开目录的fd用openat()在相对路径下操作减少路径解析的开销——openat()也是系统编程里另一个大话题这里先埋个伏笔。7. 日常开发中的一些习惯与心得文章写到这里最后一节分享几个人习惯上的经验。关于目录操作我现在写代码的默认准则是路径拼接用openat()系列函数别总拼完绝对路径再操作。openat()让你可以带着一个目录的fd去操作里面的文件既减少路径解析开销也能避免“路径被替换成软链接指向别处”的竞态风险。这是Linux系统编程里新一代API的核心思想从man openat到renameat2都是这个思路。关于用户操作我的体会是权限体系的核心不是“用户名”而是UID/GID的数值。写服务端程序时配置项里的用户名要先通过getpwnam()解析成UID后续所有判断都用UID不要在业务代码里到处比较字符串。关于调试强烈建议学会用strace。目录和用户操作是系统调用密集区strace -f -e tracemkdir,rmdir,chdir,getcwd,setuid,setgid一把梭程序底层做了什么一目了然。很多看起来诡异的问题strace一遍基本就破案了。最后说个很多人忽视的小点勤查/usr/include/linux和/usr/include/x86_64-linux-gnu/bits下的头文件。像struct stat里的st_mode位定义、struct dirent里的d_type取值、PATH_MAX的实际值全都在头文件里写着。比起网上二手资料头文件永远是最准确的一手信息。遇到琢磨不透的行为直接去查头文件和内核源码fs/namei.c是路径解析的核心实现比反复试错高效得多。写这篇文章的时候我把这些年“目录和用户操作”这块能想到的坑和方案都整理了一遍。内容偏底层但确实都是真实项目里撞过墙才总结出来的。如果你正在啃Linux系统编程建议把文中的代码片段全部自己动手跑一遍改几个参数试试异常路径理解会深很多。

Linux系统编程：目录操作与用户权限的底层原理与实战

相关推荐

[软考架构设计师论文]论云原生架构

MyEclipse下用Jsoup爬取HTML表格的实战方案

Windows安装Codex桌面版失败？微软商店错误码与完整解决方案

更多资讯

Git Reset深度解析：三种模式、误删恢复与团队协作禁区

Mac上如何只卸载OpenClaw的Companion App并保留核心Agent服务

京东云云主机企业用户优惠全解析：从认证到部署一次说透

YOLOv5遥感图像目标检测：从切片训练到推理部署全流程解析

高职计算机专业：学历不是天花板，方向和实操才是硬通货

MediaPipe + KNN 健身动作计数：从骨骼提取到状态机实战

今日更新

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

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

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

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

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

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？