fwrite和write相比，仅仅是fwrite多了一层用户级的缓存? 不同每次写入都要从用户切换到内核态，然后再回来，而是写满了stdio的缓存(512byte)以后再flush到内核?
如果我说的是正确地，那么当我fwrite每次写入的量都比较大(写入的原子远大于512byte)的时候，这个所谓的stdio的缓存，岂不是一点用都没有，平添了系统负担，反而比我直接write()更慢了?

我的这个说法有没有问题? 什么情况下fwrite的性能不如直接使用write()，fread()的性能不如直接使用read()?

基本正确。

每调用一次write/read函数就对应着一个系统调用。系统调用是比较耗时的。为减少系统调用的次数，所以才有标准IO中的缓冲机制。
所以大范围上讲，fwrite性能肯定是优于write的。
你提到的特殊情况则稍复杂一点，取决于编译器的优化策略，和标准库的实现情况。
在linux上，我没看到这方面数据的对比，我相信glibc会对此做优化。不会比write/read差。
你不妨写个小程序试试看。

什么情况下fwrite的性能不如直接使用write()，fread()的性能不如直接使用read()?

如果你的数据需要实时到位，比如一些driver，或者要跟设备文件打交道，就用write呗。省去缓冲的开销。