C语言为什么要让程序员自己管内存？
内存这种事情，为什么不能交给语言自己处理？
毕竟一旦交给程序员，就会出现很多麻烦。忘了释放，可能内存泄漏；提前释放，可能变成悬空指针；重复释放，程序可能出错；申请多少、什么时候释放，也都要自己考虑。

既然这么危险，C为什么还要这样设计？
“C最初面对的就是需要直接管理机器资源的系统程序”是一个重要的原因。
对于这类程序来说，内存不仅仅是“够不够用”的问题，还经常要关心什么时候申请，申请多大，数据怎样排列，什么时候确定不再需要，以及这些操作会不会带来额外的运行时开销。
例如，int *p = malloc(1000 * sizeof(int));
程序员明确知道，这里需要一块能够容纳1000个int的连续空间。
等这块内存不再需要时 free(p); 。
它什么时候结束，由程序自己决定。
这和垃圾回收语言有一个很明显的区别。
在带垃圾回收的语言里，程序员通常不需要决定对象究竟在哪一刻释放。运行时系统会判断哪些对象已经不再使用，再回收它们占用的内存。
这样更安全，也更方便。
但与此同时，语言运行时需要替程序做更多工作。

而C选择了另一条路——尽量少替程序员做隐藏的决定。
这对于操作系统、嵌入式系统、数据库、基础库等场景尤其重要，因为这些程序有时不仅关心平均性能，还关心资源占用和运行行为是否足够可控。
当然，严格来说，C里的内存也不是全部都要手工管理。
例如函数里的普通局部变量 int x = 10;
它的生命周期通常会随着函数调用自动开始和结束。
真正最容易让人头疼的，是动态申请的内存：程序决定什么时候获得，也要负责什么时候释放。
所以“C让程序员自己管内存”，背后其实仍然是我们前面反复看到的那种设计取舍——C把更多决定权交给程序员，
也把更多责任交给程序员。
它换来的不只是速度，而是程序可以更明确地控制资源什么时候产生、什么时候消失，以及怎样使用。

C语言