将mutex声明为全局变量是否属于不良编程实践？

核心结论 #

这个做法不算原则性的不良实践，要不要改成参数传递完全取决于你的项目规模和后续扩展需求，没必要硬套"全局变量就是错的"的教条。 #

可以直接用全局mutex的场景 #

• 你的程序是小规模工具类项目，逻辑简单，整个程序生命周期内只有这一个需要多线程读写的共享文件，没有后续扩展多文件、多实例的计划。
• 这种场景下全局mutex的逻辑是自洽的：你要保护的文件资源本身就是所有线程共享的全局资源，配一个同生命周期的全局锁，反而比反复传同一个锁参数更直观，不会产生额外的理解成本。

建议改成参数传递的场景 #

• 你计划后续扩展功能，比如未来要支持多文件并行读写、要把文件I/O逻辑抽成可复用的公共模块、或者需要给相关逻辑写单元测试。
• 全局mutex的核心问题从来不是"全局"本身，而是它会带来隐式依赖：所有线程函数不用显式接收锁参数，就默认知道这把锁的存在，后续你要给不同文件配独立锁、或者复用这段线程逻辑操作其他文件的时候，会发现代码里到处都是硬编码的全局锁引用，改起来牵一发动全身，还会平白增加不必要的锁竞争。

折中实用方案 #

哪怕你现在确定要用全局锁，也不建议把mutex和文件句柄分开零散声明成全局变量，最好把共享资源和配套的锁打包成一个上下文结构体，既保留全局写法的简洁，也给后续重构留余地：

// 把共享文件和配套锁绑定，逻辑更内聚
#include <pthread.h>
#include <stdio.h>

typedef struct {
    FILE* target_file;
    pthread_mutex_t io_mutex;
} SharedIOContext;

// 全局唯一的共享I/O上下文
SharedIOContext g_shared_io;

后续如果要改成传参模式，直接把这个结构体的指针作为线程入口函数的参数传入即可，几乎没有额外的重构成本。

不用走极端：工程实践里从来没有"全局变量一律不能用"的铁则，只要全局变量的作用域清晰、生命周期和它保护的资源完全匹配、不会给后续扩展埋坑，用了也完全没问题。为了形式上的"规范"硬给所有线程重复传同一个永远不变的锁指针，反而是毫无意义的冗余代码。

内容的提问来源于stack exchange，提问作者codeology