@xjpicism

1. 这个是我听过 Go 开发者很多次的辩解。第一，这样的用例实在少，你在标准库以外恐怕都找不出几个；第二，即便有这样的情况，从类型论角度来说，也应该是 string 和 (string, error) 的和类型，而非 (string, error) 这单独一个积类型，从抽象上来说依然是缺陷的；
2. 既然 Go 的开发者会关注「同时有错误和返回值」的小众需求，怎么「作用域结束清理」这种非小众需求、甚至 GCC Extension 和 Clang BlockExtension 同时都实现的需求又不管了呢？
3. 我的意思正是 Go 错误地删掉了 Enum ；
4. Go 没有官方的、强制性的包结构规范，因此很多开发者会这么做，甚至你去 CSDN 之类的国内网站全是教你这么做，导致产生了大量低质量、不规范的包结构，pkg.go.dev 已经被污染得不能看了。至于人工审查，你能告诉我为什么 Pypi 、Crates 、Dart Pub 、Conan 、vcpkg 上都没有我提到的这种情况吗？
5. 省的那点资源已经被每次函数调用都检查一遍是否初始化给抵消了吧。

Go 的很多设计总是给我一种「能用就行」「就差一点」的感觉（不是攻击 Go 开发者，我知道人都是很牛的大佬）。以下是我最不满意的几个点：

1. 创新性地使用了「错误亦返回值」的概念，很先进吧？但错误和返回值的关系应该表示成一种和类型（ Sum Type ），即「 A 或 B 」，Go 偏偏设计成了积类型（ Prod Type ），即「 A 和 B 」。导致很多时候不得不写出 return "", err 这样的愚蠢代码。Rust 、Haskell 等都没有这个问题；
2. 引入了做 cleanup 的 defer ，相比 RAII 其实不优不劣。但 Go 偏偏限制 defer 只能作用于「函数作用域」，导致经常要写「 for 循环里套匿名函数」的丑陋操作；
3. 直接干掉了 Enum ，把命名空间展平。后果是所有 Enum 的名称都变得非常长；
4. 仓库即包。想法很美好，但偏偏没有一个人工审查的包仓库：每次要找某种功能的包，都要在 pkg.go.dev 无数个 0 star 的、作者本意根本不是通用库的业务逻辑和模块包里翻；
5. 结构体允许不完全初始化，又不允许赋默认值。标准库里有些之前没写 New 方法的结构体，为了保证兼容，都只能在每个结构体的函数前面插一句 ensureInited() 之类的调用来补全默认字段。

小新的国际版类似物是 IdeaPad 吧，可以看看：

https://github.com/Sino-Huang/ideapad2024-power-management

https://github.com/0xless/battmngr

https://wiki.archlinux.org/title/Lenovo_IdeaPad_5_15are05

看楼主应该是联想小新的。拯救者的话有社区维护了内核驱动：

https://github.com/johnfanv2/LenovoLegionLinux

小新就不清楚了，按楼上方法抓 ACPI 方法调用即可。

之前在其他论坛接触到过楼主，所以不用猜测是不是 AI 生成或者故意学翻译腔了，我可以辅证楼主确实普通话不熟练。

1. 不好说。是否省电取决的因素太多了，理论来说 Linux 的续航会好（后台没有什么闲置无用进程），实际上会差（硬件厂家对 Windows 有特殊调校、给 Windows 开放了定制的电源管理接口等等）；
2. 哪个发行版续航都差不多，当然你选 Arch 、Debian 一类的瘦发行版，自己从头开始装桌面环境，可能会好一点；
3. LXDE 、xfce 都还可以，当然最省电的还是直接用窗口管理器（ Window Manager ，例如 i3wm 等等）。我目前是 KDE 用户，实际体验续航也差不到哪里去。

@verrickt #79

事实上关闭 swap 也不能完全防止 thrashing 问题。就像前面说的，swap 的目的是「让匿名页面和文件后备页面具有同等的交换地位，都能够在内存不足时释放」。

即使禁用了 swap ，当内存高负荷时，系统也会尝试释放内存，只不过它只能释放文件后备页面（例如从磁盘载入内存的代码段、动态链接库、文件系统缓存等）：当文件存在脏写时，还是会触发大量写盘；当内存紧缺到即将读取的链接库和文件都要被释放时，还是会导致 thrashing 。

总之，我觉得楼主的问题还是在于内存不够。Swap 只是一种帮助缓解（也可能加剧） thrashing 的手段，但 16G 内存不能流畅跑需要 32G 的程序，这是任何软件都改变不了的。Swap 最多把「跑不起」变成「勉强跑起」罢了。

@luxor

楼上关于 Overcommit 的问题解释得很清楚了。我可以再总结一下：

1. 「关闭 pagefile 当然可以提高性能」：关闭 pagefile 和性能无关，只是影响你提交总量的多少；
2. 「某些应用对已提交内存占用的优化不够，造成实际物理内存占用不高」：正是因为应用会提交更多内存（有的是因为沿袭了 Linux 的习惯，有的纯粹是在设计上难以解决），所以开启 pagefile 才是必须的。否则由于 Windows 的特性，你将连本来的物理内存都不能完全利用；
3. 「可以减少大量的磁盘读写，延长磁盘的寿命」：一方面，Windows 在交换方面已经很保守了；另一方面，如果出现「大量的磁盘读写」情况，说明平时的工作负载（注意！这里说的是实际的内存使用。仅仅提交很多内存而不使用，并不会产生任何磁盘读写。参考楼上）对内存来说已经不堪重负了，那么升级内存是最佳解决办法，而 pagefile 也能作为一种后备资源来在瞬时高负载时分担一下。关掉 pagefile 属于纯纯的掩耳盗铃、自欺欺人，其结果是工作负载运行不起来了。而且由于第 2 点，就连原本的物理内存都无法完全利用了，百害而无一利。

稍微了解一下操作系统原理吧，避免几个误区：

1. 「已提交」和内存占用没有半毛钱关系，也不是程序「恶意偷内存」。哪怕你的已提交显示 1 TB ，物理内存只有 8 GB ，也完全不能代表你的电脑内存满了或者没满。「已提交」的唯一意义是告诉你「所有应用宣告申请了这么多内存」，但「申请」不等于「用」：很多使用自己的用户空间内存分配器的程序会直接从系统那里「申请」过来一大把内存（甚至比实际物理内存还大），然后慢慢用。真正的内存占用是指程序「用」的部分。这部分你应该通过 Resident Set 或 Working Set 来估算；
2. 虚拟内存是 Windows 滥用的错误术语之一。虚拟内存本身是操作系统的基本概念，指为每个进程都需要分配一个独立的地址空间，这个地址空间映射到物理内存页面中。你说的这项能关掉的功能应该是指交换空间 / 分页文件（ Swap ）。
2. 交换空间关掉并不能让系统在高负载下变快。相反，我不推荐在任何场景下关掉。它的目的是为了让匿名页面和文件后备页面具有同等的交换地位，都能够在内存不足时释放。关掉后，只有后者能释放，所以等于是在高负载下系统能强制释放内存的手段变少了一个，只会让系统更不稳定。

问题来了，有什么工具刷运营商的 CDN 流量吗

@masterclock

> 这个项目与 awesome-c 、搜索 有什么区别？

（ 1 ） awesome-c 并非记录了所有库；(2) awesome-c 没有给出任何有关库的详细信息，且其中 80% 的库都是属于「年久失修」的类型，搜索起来非常费时。

> 如果是精选的，以 C 的生态，必定是 bias 、opinionated 的

何出此言？

> 仅仅只是一个条目、一句介绍显得过于单薄了

是的，所以我在介绍时非常强调对比性。如果列出了多条项目，一定要找到其差异的地方：是否更全面/紧凑？是否兼容特定 C 标准？性能是否有明显差异？是否维护良好？有关这一点，可以在列表中任意查找验证。

> 同时 OP 应该是专业的 C 程序员，应该在某个领域具有比较深的积累

「我不是专业的 C 程序员」里的「专业」是指「以写 C 为职业」，不「专业」 != 啥都不会… 要是啥都不了解就来写这种项目，我不是给自己找不痛快嘛。

至于你说的「某个领域具有比较深的积累」，我做 Linux 内核驱动和嵌入式比较多，不过都不是公开项目。这一点也可以从列表中验证：网络、JSON 解析部分的库改动是最勤快的，因为这一方面我确实了解不深。

> 否则怎么知道推荐的某个条目是不是这个领域里的常规用例

谢谢你的建议。正如我反复强调的，目前的评选标准是维护最积极、最流行甚至已成为事实标准（当然还包括可移植性、性能等），我认为这些都是客观的评判方式：如果某个领域最流行的库在 GitHub 上只有几个 star ，很「不常规」的用例反而有几千 star ，或者在 StackOverflow 上根本无人问津，那反倒是一桩怪事了。

最后，我发到 V 站来自然是为了让更多人看到这一项目，这样才有可能有路过的「这个领域里的」大佬来提出意见，让我有机会修正为你说的「常规用例」。

这是一个社区共建列表，不是一个个人维护项目。我不明白为什么我被一而再、再而三地要求证明我自己的个人水平或项目的「意义」来为列表背书，因为我的个人水平和列表的质量根本不是一码事。

如果你认为列表质量低，请直接说明哪一条低、改成什么项目更好；如果你认为有更好的选择，请直接把选择甩到我脸上让我学习，不必拐弯抹角；如果你压根没点进去看过项目，只是看完我的描述就想找个网友来怼一怼，那我也欢迎。虚无缥缈的指责无益于项目的进步。

@tool2d #7

> 现在有了 GPT4 ，需要找啥库问它，十有八九错不了。

本着谁主张谁举证的原则，请证明这句话。不然全成我一人在说道了，有偏袒自己之嫌。

如果一定要我举证：(1) GPT-4 不是每个人都在用或者有能力用；(2) 我当然问过这个问题，GPT-4 回复的均是一些年久失修或者在某些 StackOverflow 中回答过的冷门库，反复增加条件好几次才慢吞吞给出 libuv ，而且还是同列在五六项不能用的库之中的。这恰好是我想避免的；(3) 小小滑坡一下，如果 GPT-4 就能解决所有问题，那 GitHub 上所有同类项目都应该不需要存在了。事实是这样吗？我个人从 GPT-4 处获得的回答，有一半都是错误的。

再强调一次，举证责任不在我。如果你想就这点讨论，请先给出任何一点自己的依据。

> 小白不会用，指的是新人很少有用 C 语言写项目的

要么我理解错你的意思，要么你在偷换概念。我们讨论的「小白」就是「学习 C 语言项目的小白」而不是「初次接触编程的小白」吧？怎么这部分人又变成「很少有用 C 语言写项目」呢？

> 产出和学习周期太长了。都是老人在用 C ，他们写的代码，基准在线，很糟糕的 C 代码项目极少。

这些是客观事实。我认为，「产出和学习周期太长」的一个（不是全部）重要因素正是 C 语言生态差，各种配套设施杂七杂八得多，而且质量参差不齐。那么提出一个 curated list 我认为是有益的。

若因此不做，不又陷入「生态差->没人学->生态差」的循环了？而且预想一个完美的庞大「老人」群体（而这部分人很可能没有你说的那么多。看看 GitHub 上 C 库的代码质量就知道了），然后争论他们如何懂，这和项目是否有意义，我认为是关系不大的。总是有人要学习的，我的项目哪怕帮不到别人，能帮到我自己也是好的。

@liprais #5 我实在没有理解这句有什么问题，表达了我怎样的自命不凡。烦请高抬贵手指出。总不是指我用 Google 或者自称不专业吧。

如果你是说「在自己不了解的领域，还好意思挑选出来推荐给别人」的话，我在挑选中参考的都是客观指标（ Star 数、维护频次、文档、可移植性、相关搜索数……），尽量不掺杂个人情感；另外，就像我下一句说的，「有的选择可能明显存在我的个人偏见」。事实上这个列表今天在和其他人交流中已经修改很多次了，原先自主主张添加的一些完全不了解的库基本已经轮替一轮。

@liprais 你对于推荐的项目或者我的态度有什么建议吗？我反复读了一遍主贴，没有看到任何高高在上或者试图表明「我随手一推荐的都是对的，你们用的都是错的」的观点。相反，我一直在反复强调「我不是专业的 C 程序员」「其中一些领域我也不了解」「人工挑选或是利用 Google 等搜索引擎搜索得到的」。

至于我给楼上的回复，我也没有看出试图证明「我比你聪明」的意思。你是对哪一句不满意呢？

如果你认为自己比我聪明，欢迎提出理由。仅仅甩一句阴阳的话不能证明任何观点，除了你的戾气。我不认为你是来这里寻开心的。

@tool2d

> github 上的项目，C 语言应该是存量最多的

问题就在于存量是最多的。多并非是好事，反而会将那些真正有用的库稀释了，查找起来会更困难。而且大量库（例如 GNU ）几乎不在 GitHub 上发布，而是自建服务或者使用其他版本管理服务。

> 想找什么直接搜关键词，大概率能找到合适的

就我使用的体验，想找到有用的库很难。C 早期库的特点是很多不能注重模块化，因为类型和接口高度耦合，为了性能必须把一簇功能放在一起发布，例如 Glib 、gnulib 等。就「跨平台 Socket 库」这个需求，我初用 C 时好一顿找，Google 「 portable socket library for c 」翻个底朝天都没找出需要的。最后发现 libuv 的介绍是「 Cross-platform asynchronous I/O 」……汗颜，水平不够是真的没法精准描述自己需要的东西的。

> 这种推荐，大神不会去参考，小白也不会去用

大神不会参考我理解，「小白也不会去用」何出此言？

> 普通人看到茫茫多的 C 代码，也只能劝退。

哪里有茫茫多的 C 代码？我这应该是个 curated list 类型的项目吧。只有标题、简介和链接啊。

> C 的爱好者，一般都是希望了解底层运行原理，但是你不自己造一个轮子出来，又怎么能了解原理呢。

语言有两个目的：使用和学习。使用自不必说，学习时先找到一个好的项目作参考，也不冲突。我猜想你的意思应该不包含「学语言必须闭门造车，不要参考任何项目」这一层观点吧？

如果确定两边一定只能中转可以看看 n2n ，省时省力，免去纠结 zerotier 的配置

支持一下