Linux性能调优实战：RH134内核参数与tuned服务全解析-北京尧图网络

1. 从RH134课程目录看性能调优的定位红帽RH134作为RHCE认证的第二门核心课程延续了RH124对基础运维能力的考察把重点从会用系统推向能调好系统。整套课程按部就班地覆盖存储管理、逻辑卷、计划任务、内核启动流程、网络配置最后落在一个容易被初学者忽视的章节——调优系统性能。说实话我在学习RH134前半程时也觉得性能调优离日常操作很远毕竟考试环境里虚拟机资源充足系统默认参数一般不会出什么问题。但真正动手把几个子系统压测一遍之后才发现这一章考察的能力恰恰是运维工作中最值钱的部分当系统变慢时你能不能快速定位是哪一块的瓶颈并给出可落地的调整方案。RH134的调优章节主要围绕三件事展开用系统自带工具评估当前负载状态、通过内核参数与systemd资源控制调整运行策略、使用tuned服务按场景自动切换性能配置。这三件事不是割裂的实际生产环境中的调优流程通常是监控发现数据异常 → 确认瓶颈方向 → 修改对应配置 → 重启服务或加载新参数 → 二次压测验证。整个闭环思路和RH134考试中考察的故障排查题如出一辙。这一章适合谁呢一是准备考RH134或RHCE的考生尤其是看到awk、sed脚本就头疼、担心性能题无从下手的人二是刚入职的运维工程师想在业务报警时不再只会重启服务器三是所有想理解Linux系统底层工作机制的开发者。它不要求你有深厚的内核源码阅读功底只要按着课程的逻辑把工具用熟练、把参数的意义搞清楚面对未知性能问题时就有章可循。2. 先会看病再开药系统性能评估工具的实战组合2.1 用top快速判断CPU与负载走势学习性能调优的第一个误区就是调优两个字以为一上来就要改参数。实际上RH134教材明确传递的理念是调优之前必须先量化当前的状态再用数据说话。top命令是我日常登录服务器后敲得最多的命令没有之一。它的输出信息密度很高顶部几行包含了负载均值、进程总数、CPU使用率占比、内存与交换分区使用情况下方的进程列表则按CPU占用率排序默认每3秒刷新一次。你需要注意的细节是top输出的CPU百分比有多项指标us用户态、sy内核态、ni优先级调整过的nice值进程占用、id空闲、wa等待I/O完成、hi硬件中断、si软件中断、st被虚拟机管理程序偷走的时间。我刚学习时只盯着us和id看后来才发现wa这一项才是磁盘性能瓶颈的关键信号。wa比例持续偏高说明CPU在空转等待存储I/O完成这时就算把CPU参数调到天上去也无济于事。top还有一个容易被忽略的功能是进入交互模式后按数字1可以展开每个CPU核心的使用情况多核服务器上某个核跑满而其他核空闲这类负载不均的问题光看平均值是发现不了的。除了topLinux还提供了mpstat用来按处理器分别报告统计信息以及pidstat用于按进程细分CPU使用情况。RH134考试环境里未必装了sysstat全家桶所以稳妥的做法是先把top用透再学会用vmstat补足内存与I/O侧的数据。2.2 vmstat与iostat定位瓶颈方向的黄金搭档vmstat是一款历史悠久的系统监控工具它和top的区别在于输出的是瞬时快照叠加时间间隔内的聚合统计值更适合观察变化趋势。常用写法是vmstat 2 5表示每2秒采集一次、共输出5次。需要重点看的是procs下的r和b列、cpu下的us/sy/id/wa列以及swap下的si和so列。r列代表等待运行CPU的进程数如果这个数字长期超过CPU核心数说明CPU就是瓶颈b列是被阻塞的进程数通常在等待I/O资源数值偏高就要去查磁盘或网络了。说到这里必须吐槽一句很多人看内存只看free命令的输出然后一看可用内存只剩几百兆就慌得要加内存条。实际上Linux对内存的管理策略是能用就用空闲内存在满足条件时会用作文件缓存cache这是提升读写性能的正常机制不是内存泄漏。真正要警惕的是swap分区持续写入也就是so列长期不为0说明物理内存真的不够用了系统在内存在换页的泥潭里挣扎。这时候的解决方向是调整vm.swappiness参数、释放缓存或者直接扩容内存而不是盲目加swap空间。iostat则是评估块设备读写能力的主力工具输出中包含tps每秒传输次数、kB_read/s、kB_wrtn/s以及%util设备繁忙度。%util接近100%时表明磁盘已经满负荷运转但你要清楚它反映的是设备侧的繁忙程度如果磁盘阵列做了条带化或者底层有缓存加速%util高并不直接等于I/O延迟恶化要结合svctm和await这类延迟指标一起判断。实际压测中我最常做的组合是开三个终端分别跑top、vmstat 1和iostat -x 1人为构造压力之后看哪个终端的指标先爆表——谁先爆表瓶颈就在哪个子系统。2.3 用sar做历史回溯性能排障的后悔药生产服务器往往不会在出故障的当下恰好开着监控终端这时候sysstat包里的sar命令就成了查历史数据的后悔药。sar的机制是后台定时采集系统各项指标并落盘默认保存最近7天的数据。用法上最常用的是sar -uCPU、sar -r内存、sar -bI/O和sar -n DEV网卡流量。服务器下午3点卡顿你手头又没有任何现场截图那就直接sar -u -f /var/log/sa/sa15看看15号那天哪段时间的CPU使用率出现了尖峰。不过需要提醒的是性能调优最忌讳的就是在信息不足的情况下靠直觉瞎猜。任何工具输出都只是现象不是结论。比如top里看到某个进程CPU占用高你要进一步确认它是正常的业务计算高峰还是代码里出现了死循环又或是被攻击后成了挖矿进程。确认手段包括用ps -ef查看命令行、用lsof查看它打开了哪些文件、用strace跟踪系统调用。RH134考试不会考到strace这么深但建立这种由表及里的排查意识对备考和实际工作都是加分项。3. 内核参数调优不是每个参数都必须动3.1 理解/proc/sys与sysctl的关系Linux内核的大部分运行参数都可以通过/proc/sys目录下的虚拟文件进行查看与修改。这些文件以点分隔的层级命名sysctl命令只是提供了更友好的读写界面。临时修改时echo数值 /proc/sys/内核参数路径直接生效但重启后失效而sysctl -w参数名数值的作用类似。要想永久生效按RH134的要求应该把配置写入/etc/sysctl.d/目录下以.conf结尾的独立文件然后在命令行执行sysctl --system重新加载。很多初学者不理解为什么要用/etc/sysctl.d而不是直接改/etc/sysctl.conf其实这体现了红帽对配置管理的设计理念把不同关注点的配置拆分到独立文件便于自动化工具和运维人员按模块维护。你负责的应用需要的参数就放到99-app-tuning.conf这样的文件里其他模块的配置互不干扰。我在学习阶段养成的习惯是任何参数的改动都先在命令行用sysctl -w临时生效验证效果确认无副作用之后才写入配置文件。考试环境中虽然不强制要求这一步但这个习惯能让你在生产环境少踩很多坑。3.2 高频考点vm.swappiness、vm.dirty_ratio与dirty_background_ratio在RH134的调优章节里内存相关的内核参数是考察重点其中出镜率最高的就是vm.swappiness。这个参数控制内核在回收内存页时对匿名页和文件缓存页的偏好程度取值范围0到100默认是30。值越低内核越倾向于保留匿名页也就是进程实际占用的内存尽量避免把进程换出到swap值越高内核越积极地使用swap来释放物理内存。对现代服务器而言物理内存普遍充足把swappiness调低到10左右通常能减少无谓的swap换页改善应用响应延迟。但这里有个理解误区swappiness0并不是永远不使用swap而是在内存压力极大时依然会换出。只要系统还有足够的空闲内存和可回收缓存调低或者调高swappiness在日常负载下可能根本感觉不到差别。我个人观点是如果某台机器swap使用量持续增长不要第一反应就去调swappiness而是先看内存本身是否真的不够用。调这个参数只是改善回收策略无法凭空变出内存。与swap紧密相关的还有两个脏页参数vm.dirty_ratio和vm.dirty_background_ratio。这两个参数控制内存中待写回磁盘的脏页数量和触发后台刷写的阈值。dirty_background_ratio默认是10表示脏页占系统内存的10%时后台开始刷盘dirty_ratio默认是20达到这一比例后进程的写入操作会同步阻塞强制刷脏页。如果你把这两个值调大写入操作能更快返回给应用但一旦掉电内存里未落盘的数据丢失风险也随之增大。对数据库类服务适当降低dirty_ratio反而有利于平滑写盘。这个参数的调整要结合业务对数据安全性的要求来判断没有绝对的最优值。3.3 网络参数排查丢包与连接数瓶颈RH134对网络性能调优的考察比RH124更深一层不再只满足于配通IP和路由而是要求你能够查看并调整协议栈相关的内核参数。比较常见的有net.core.somaxconn单个监听socket的accept队列上限、net.ipv4.tcp_max_syn_backlog半连接队列长度、net.core.rmem_max和net.core.wmem_max套接字收发缓冲区上限。高并发场景下如果应用日志里出现connection refused往往不是进程挂掉了而是accept队列满了新连接直接被内核丢弃。处理思路上先确认当前队列长度是否已经顶到上限可以用ss -lnt查看Send-Q和Recv-Q有需要再提高somaxconn同时应用软件层面也要同步调整监听队列参数。我就见过把内核somaxconn调到65535但Nginx配置里backlog还留在512的案例说明调优必须是应用层和内核层联动的一整套操作。另一个容易被考到的是tcp_tw_reuse。这个参数允许在TIME_WAIT状态的连接被安全复用对大量短连接的场景能显著减少新建连接的系统开销。不过改它的前提是接受可能导致的连接复用风险并且旧内核中的相关实现可能有兼容问题生产环境修改前最好先在测试环境压一轮。RH134考试不会让你写调优脚本但会在概念题中考察内核参数与系统行为的对应关系这一类参数务必理解清楚再记忆。3.4 调整进程优先级nice值的正确用法严格来说nice调整进程优先级不属于内核参数调优而是进程调度层面的调优手段但RH134把相关内容安排在调优章节内学习和考试时不应忽略。nice值的范围是-20到19数值越低代表优先级越高越容易被调度到CPU执行。普通用户只能调高nice值也就是让自己进程的优先级变低如果想调低nice值提升优先级需要root权限。renice命令用于修改已运行进程的nice值。实战中调整nice值最有用的场景是一台服务器上既跑着核心业务又跑着备份脚本备份任务一到点就把CPU吃满业务响应明显变慢。这种情况下把备份任务的nice值调高让它变成低优先级任务核心业务的调度不会受太大影响。但是要注意nice只影响CPU调度优先级对I/O密集型的任务效果有限磁盘读写抢的是I/O带宽而不是CPU时间片想限制I/O使用率需要用ionice命令设置进程的I/O调度优先级。这类细节考试中不直接考命令的具体参数但会以场景题的形式考察你判断该用哪种手段。3.5 sysctl调优的通用操作流程与验证方法根据RH134的认证目标和实际运维经验sysctl调优应当遵循一套可复用的操作流程。首先用sysctl -a或针对性查询sysctl vm.swappiness、sysctl net.core.somaxconn等确认当前值。然后修改临时值并观察应用表现一般给系统10到20分钟时间收集新数据不能改完立刻下结论因为缓存、连接池等机制会让效果延迟显现。确认效果良好后写入/etc/sysctl.d/下的独立配置文件每个参数加注释说明修改原因、时间、期望效果方便后来人维护。最后执行sysctl --system验证所有文件能被正确加载再用sysctl 参数名检查最终生效值。我踩过的坑之一是写错配置文件里的参数名sysctl --system会静默跳过无法识别的参数但不报错导致我一度以为参数已经生效实际查询才发现根本没加载。应对办法是执行加载后必须逐个检查关键参数的实际值不要偷懒只看命令输出里有没有error字样。参数拼写方面sysctl参数名内用的是点而不是下划线比如vm.swappiness写错成vm_swappiness就不会生效。这些细节虽然不起眼在紧张的考试环境里却是拉开分差的地方。4. tuned服务按场景自动切换性能方案4.1 tuned的架构与配置目录结构tuned是红帽推出的系统调优服务它的核心理念是把性能优化从人工逐个改参数变成按场景选择预设方案。服务后台存在一个tuned守护进程根据你选中的profile自动应用一组预定义的内核参数和系统设置。RH134对tuned的要求包括能够查看当前生效的profile、切换其他profile、以及理解各种profile的适用场景。配置层面tuned的profile文件存放在/usr/lib/tuned目录下每个profile一个子目录主配置文件名为tuned.conf。系统当前的生效配置在/etc/tuned/tuned.conf中通过软链接指向/usr/lib/tuned下对应目录。升级系统或安装新内核时tuned服务会自动尝试应用与当前环境兼容的配置这一点在生产环境里需要格外注意升级前最好检查一下tuned服务的运行状态避免它擅自变更了线上关键参数。4.2 RH134高频profilethroughput-performance与latency-performancetuned自带很多预置profile而且不同版本之间profile列表会有差异但RH134课程里重点讲的、以及考试中最可能遇到的几乎都是这两个throughput-performance和latency-performance。前者面向吞吐量优先的场景内核参数目标是把CPU调频策略设为performance模式、增大文件系统预读窗口、适当提升脏页回写阈值适合文件服务器、计算集群这类追求单位时间内处理更多数据的任务。后者面向延迟敏感的场景重点在于尽量缩短单个请求的响应时间比如数据库在线事务处理它会禁用CPU节能状态让CPU保持在高频运行以减少唤醒延迟。实际选型时判断依据很简单业务关心的是每秒处理多少请求吞吐量还是每个请求多快返回延迟。大多数互联网后端应用更在乎后者所以生产环境里latency-performance的出场率更高。如果你想调整某个参数但不是全部参数tuned也支持在profile目录下放一个tuned.conf的覆盖文件然后通过include语法继承预置配置并局部修改。这和我前面强调的不要全盘照搬、按需微调的思路一脉相承。4.3 使用tuned-adm进行查看与切换操作层面tuned-adm是最主要的客户端工具。tuned-adm active查看当前生效的profiletuned-adm list列出所有可用profile并标注哪个处于活动状态tuned-adm recommend则输出系统推荐的profile这个推荐值基于系统硬件类型和发行版默认策略计算通常是虚拟化环境推荐throughput-performance物理机推荐balanced之类。切换profile用tuned-adm profile 名称关闭调优则用tuned-adm off。一个值得注意的细节是tuned不仅调整内核参数还可以通过插件机制调整磁盘调度器、CPU动态调频策略、无线网卡省电模式等。比如在虚拟机里磁盘调度器默认可能是none也就是noop在物理机上可能是bfq或mq-deadline这些都可以通过tuned的disk插件统一管理。考试中可能会给你一段tuned.conf内容问你某个配置插件的key的含义所以学习时不要只看tuned-adm命令也要能读懂配置文件格式。4.4 自定义tuned profile的实战步骤自定义profile是RH134调优章节里少数需要动手编写配置的考点好在流程并不复杂。第一步创建配置目录通常在/etc/tuned/下新建以profile名命名的目录比如/etc/tuned/myprofile/。第二步在该目录下创建tuned.conf内容大致分为主配置段、sysctl配置段和插件配置段三段。主配置段用[main]声明是否继承其他profilesysctl段以[sysctl]开头下面逐行写参数名数值插件段则是[plugin名称]加对应key。写完配置文件后需要执行tuned-adm profile myprofile激活激活失败时用tuned-adm verify检查是否有配置冲突或无效插件。我的个人建议是自定义profile一定要保持最小覆盖原则只写你需要覆盖的参数其余交给继承的基础profile。举例来说你在latency-performance基础上只需要修改vm.swappiness那就在tuned.conf里写includelatency-performance然后[sysctl]段只写vm.swappiness行。这样既保证了与红帽官方维护的基线配置兼容又能在系统升级后继续获得官方对基础profile的安全修补属于性价比极高的实践。5. 用systemd限制资源把后门堵在配置层5.1 查看服务当前资源占用状态systemd作为Linux下所有服务的守护者不仅负责启动和管理进程生命周期还提供了一套完整的资源控制能力。RH134在调优章节引入系统资源控制的考察点主要原因在于很多性能问题的根源是某个失控的进程把整台机器拖垮与其事后调内核参数不如在服务启动时就把资源上限设定好。排查阶段常用systemctl status显示服务的基础信息但查看资源占用更直接的方式是systemd-cgtop它按控制组实时显示各组CPU、内存、I/O的使用量相当于cgroup版本的top。实际运维中还有一种常见场景是systemctl status里明明显示服务是active状态业务却频繁超时这时候可以执行systemctl show服务名查看MemoryCurrent、CPUUsageNSec这些字段确认服务实际消耗的资源是否已经接近之前设定的Limit值。如果服务进程反复被杀或者OOM但系统日志里没有明显报错优先检查是不是忘记给服务设置MemoryMax导致它把内存耗尽后被OOM Killer选中干掉了。5.2 CPU与内存限制的配置方法systemd服务单元文件中对资源限制的配置主要有几个关键项。CPUQuota用于限制服务最多可使用多少比例的单核CPU写作CPUQuota50%代表最多使用半个核心的算力。MemoryMax用于限制服务物理内存使用量的硬上限超过之后服务会被OOM Killer杀掉MemoryHigh则是一个软限制超过后内核会积极回收该服务的内存页但尽量不杀进程。TasksMax可以限制服务内可以创建的最大任务数防止进程无限fork拖垮系统。修改服务限制有两种方式一种是直接编辑/usr/lib/systemd/system/目录下的原始单元文件不推荐升级会被覆盖另一种是追加配置到/etc/systemd/system/服务名.d/override.conf文件中这种方式叫drop-in配置这也是RH134教材强调的标准做法。我自己的习惯是每次改完drop-in都执行systemctl daemon-reload重新加载配置再重启服务让配置生效。需要记住重要原则这些配置只会影响单个服务的资源占用并不是全局的系统级调优手段。5.3 结合CPUAffinity绑定核心系统级调优中CPU亲和性绑定很容易被忽略但也很实用。默认情况下内核的调度器会把进程放到系统的任意一个空闲CPU核心上执行这本身没什么问题但对延迟敏感的业务来说频繁在不同核心间迁移会让CPU缓存命中率下降。systemd单元里的CPUAffinity选项可以把服务固定到指定的核心列表上。写法是CPUAffinity0-3或CPUAffinity0 2 4 6含义是把服务限定在这些CPU核心上运行。我实际使用中发现绑定CPU核心需要先确认服务器上有没有其他高负载进程在抢同一个核心。比如数据库服务绑在0-3号核心结果监控agent也绑在那里双方互相干扰效果还不如不绑。稳妥的做法是先留出专用核心给需要绑定的服务通过isolcpus内核启动参数把部分核心从通用调度池中拿掉再让服务独占绑定。这些高级内容RH134考试一般不深究但对超线程环境和NUMA架构的知识有所了解能让你在碰到相关应用题时不慌。6. 性能调优常见问题与排查实录6.1 场景一CPU使用率不高但系统响应缓慢这里我复盘一个生产环境的真实案例。某台运行Java应用的服务器反馈接口响应变慢我登录后第一眼看topCPU总体使用率不到30%内存也充裕看起来一切正常。但vmstat 1输出显示r列数值持续高于8而且进程的上下文切换次数cs列异常的高。r列高但CPU空闲说明有大量进程在等待CPU调度可CPU明明没跑满这不矛盾吗矛盾点在于CPU核心数有限假设机器只有4核r列数值10意味着平均每个核上有2.5个任务排队整体使用率当然不可能高到哪里去而且操作系统把大量时间花在进程切换上真正用于用户态计算的时间反而少了。找到原因后再看系统里有没有大量短生命周期进程不断创建销毁后来定位到是定时任务脚本每隔几秒启动一个临时进程处理数据频繁fork导致调度压力巨大。解决手段是把脚本改成常驻服务配合worker轮询处理任务r列立刻降了下来。这个案例提示了一个核心经验性能分析不能只盯着资源使用率这一项指标还需要结合运行队列长度、上下文切换次数这些过程指标综合判断。6.2 场景二修改内核参数后系统启动异常内核参数调优有一个哀伤的常见问题参数改坏了系统起不来。RH134备考阶段恰好也是折腾内核参数最凶的阶段不少人把vm.dirty_ratio调到90或者误改了kernel.pid_max重启后系统行为异常。处理这类问题的第一个通用办法是进入单用户模式或紧急模式把改过的配置文件恢复原状然后重启。第二个办法是在GRUB启动菜单里临时追加内核启动参数来覆盖故障配置比如systemd.unitrescue.target直接进入救援模式。面对这种场景我的经验是永远记住你改过哪些参数改之前把原值记录下来。很多人改坏之后根本想不起来自己动过什么只能逐个排查配置文件浪费时间也增加了风险。另外跟内核参数相关的配置改动务必先验证语法无误、临时值生效正常再写入持久化文件。手滑改错一个参数名导致服务全部无法启动这种教训亲身经历一次就能长记性。6.3 场景三tuned切换与sysctl手动修改互相覆盖这个坑特别隐蔽但也特别值得说。有同学手动通过sysctl命令设置了某个内核参数过了几天发现参数值又变回默认了排查了很久最后发现是tuned服务在重启或切换profile时把系统参数应用了一遍。tuned在设计上会把profile内定义的参数在激活时强制写入系统而且它会维护一个基线记录周期性检查参数有没有被外部改动如果发现被改就按profile重新应用。这就带来一个重要规矩如果你同时使用tuned管理和手动sysctl管理参数必须有明确的分工。要么完全以tuned为准所有参数都收敛到tuned profile里管理要么在tuned配置里排除不想管的那几个参数。实际操作中可以在tuned的配置里加上这个参数并设为确定值保证每次tuned重启后都能回归到预期状态避免两边拉锯。对RH134考试而言理解这个交互机制比背诵命令重要得多因为它考察的是对系统组件的整体理解而不是孤立的知识点。6.4 场景四内存看似大量空闲却频繁使用swap还有一类场景在虚拟机里很常见free -h显示物理内存还剩一半以上但swap的si和so列持续有数值。初看很让人费解内存明明够用为什么要用swap其实原因通常是内存页不够连续或者某些页面已经被标记为可回收内核在内存分配压力下把这些页换出以便腾出连续物理内存块。另一个常见原因是某些进程在很长一段时间内处于空闲状态内核把它们换到swap以释放内存给文件缓存用这类进程重新被唤醒时再换回来这是内核正常的冷热数据交换策略不一定是问题。对这类的排查思路先看vmstat里si/so的平均速率如果只是瞬时少量换页不用管如果持续高速换页追踪是哪类进程导致的通常是大规模内存分配和释放的场景。然后评估业务容忍度再决定是否需要调整swappiness、设置服务内存上限、或者优化应用内存使用模式。这个案例说明了一个通用原理调优的出发点永远是业务不卡、系统可用而非追求某个指标的极限值。理解这一点学习RH134时就不容易被各种参数绕晕考试时面对情景题也能抓住本质。7. 基于RH134考核思路的实践建议围绕RH134的最终考试把调优章节的内容按考察方式做一个划分或许能帮你把复习思路理得更清楚。RHCSA阶段考察的是会不会执行RH134阶段更偏向会不会判断所以这一部分不要死记参数默认值更重要的是理解每一个调优手段在什么场景下使用、会产生什么影响、用什么命令去验证。我在实际练习中给自己设计了一套虚拟实验流程推荐备考的同学也试一下。环境可以是本机虚拟机装好sysstat包然后按这个循环来第一步启动一个压测工具没有专业工具就写个循环脚本模拟CPU密集任务持续让某个子系统达到高负载第二步不急着看工具凭经验猜测瓶颈在哪里然后用top、vmstat、iostat交叉验证第三步针对瓶颈修改系统相应参数再用同样的压测任务跑一遍记录优化前后的吞吐量或响应时间变化。这个制造问题→分析问题→解决问题→复盘效果的闭环和RH134故障排查的业务逻辑完全一致练过一次之后你对内核参数的理解深度会远超只阅读理论的状态。学习顺序上建议先把tuned的知识点吃透——它是红帽提供的官方调优入口也是最容易在考试中拿分的部分。然后学习sysctl查看和修改基础参数配合systemd服务资源限制形成场景化调整和进程级兜底的立体认识。最后才是深入理解内核参数背后的机制这部分能掌握多少决定你在真实工作中的调优水平而不是只看几个配置数值的皮毛。纯粹的背命令应付考试没问题但想成为一个能独当一面解决性能问题的运维还是要回到理解系统运作原理的原点上来。

Linux性能调优实战：RH134内核参数与tuned服务全解析

相关推荐

C#火车信息管理系统源码还原：数据库初始化到购票退票实战解析

Windows搜索卡住一直转圈？从服务、索引到注册表的排查修复攻略

Redis AOF持久化深度解析：fsync策略、重写机制与生产实践

更多资讯

OpenCV+MediaPipe实现石头剪刀布手势识别：关键点检测与几何规则

磁阻存储器MRAM与PIC18F4458的工业数据存储方案

Figma版本历史时间机器：Figma Console MCP如何用diff引擎与二进制搜索blame追踪每次设计变更

STM32F303RC驱动MR25H40CDF：工业级SPI MRAM存储方案与掉电安全设计

MRAM替代Flash：工业嵌入式非易失存储完整指南

手机里舍不得删的5款安卓神器

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

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

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

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

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