先说结论，单次性能，file_put_contents要比fwrite好，这个也很好理解，因为写入文件，file_put_contents就一行代码，fwrite至少三行，虽然不是说代码行少就一定快，但就这个写入功能来说，file_put_contents就等于fopen fwrite fclose，之所以前者快，就是因为一次api交互，直接干了这三件事，后者有三次api的开销。
再说问题，其实不能说是问题，应该说是一个需要注意的点，默认情况下，两者都是不是使用独占锁的方式运行，所以在高并发下，会有写入的内容被覆盖的问题。这里需要通过独占锁的方式来解决。
之前过某篇文章，对比file_put_contents和fwrite的性能，是用的循环100w次写入的方式对比，记得当时的结论是，file_put_contents用了300多秒，fwrite 10秒，那是因为，他讲fopen和fcolse放到了循环外，如果你100w拼成一个长字符，最后一次写入，那肯定更快。所以很多结论都是有特定场景的。
实验一、
实验二、
实验三、
实验四、
当然了，这两个函数，和你的系统，软件版本，文件系统有很大的关系，linux下的性能明显比window要好一些。所以这里就像我上篇文章说的，web程序，和你做一个类似的批处理程序，写法是不一样，因为着重的点不一样。就是因为没有锁，所以才有好的并发效果，但是你如果一定要强制写入的完整，就需要牺牲并发的性能。
如果我们在做文件处理脚本，就适合使用颗粒度更小的函数，这样你才能在关键点，通过函数、系统逻辑特性做出优化。所以没有银弹，任何的东西都是相对的
文件锁有两种：共享锁和排他锁，也就是读锁(LOCK_SH)和写锁(LOCK_EX)
文件的锁一般这么使用：
$fp = fopen("filename", "a");
flock($fp, LOCK_SH) or die("lock error")
$str = fread($fp, 1024);
flock($fp, LOCK_UN);
fclose($fp);
注意fwrite之后，文件立即就被更新了，而不是等fwrite然后fclose之后文件才会更新，这个可以通过在fwrite之后fclose之前读取这个文件进行检查
但是什么时候使用lock_ex什么时候使用lock_sh呢？
读的时候：
如果不想出现dirty数据，那么最好使用lock_sh共享锁。可以考虑以下三种情况：
1. 如果读的时候没有加共享锁，那么其他程序要写的话（不管这个写是加锁还是不加锁）都会立即写成功。如果正好读了一半，然后被其他程序给写了，那么读的后一半就有可能跟前一半对不上（前一半是修改前的，后一半是修改后的）
2. 如果读的时候加上了共享锁（因为只是读，没有必要使用排他锁），这个时候，其他程序开始写，这个写程序没有使用锁，那么写程序会直接修改这个文件，也会导致前面一样的问题
3. 最理想的情况是，读的时候加锁(lock_sh),写的时候也进行加锁(lock_ex),这样写程序会等着读程序完成之后才进行操作，而不会出现贸然操作的情况
写的时候：
如果多个写程序不加锁同时对文件进行操作，那么最后的数据有可能一部分是a程序写的，一部分是b程序写的
如果写的时候加锁了，这个时候有其他的程序来读，那么他会读到什么东西呢？
1. 如果读程序没有申请共享锁，那么他会读到dirty的数据。比如写程序要写a,b,c三部分，写完a,这时候读读到的是a，继续写b，这时候读读到的是ab，然后写c，这时候读到的是abc.
2. 如果读程序在之前申请了共享锁，那么读程序会等写程序将abc写完并释放锁之后才进行读。
程序本天成，妙手偶得之！我们只是代码的搬运工！
