搞了半天終於找到原因了，這絕對是后端的問題。我把解決方案列在這里：
首先我之前的做法是，請求一個視頻鏈接，然后無腦返回一整個視頻文件。
對於chrome沒有問題，只能說chrome兼容性做得比較好，並不是說視頻傳輸協議就可以這樣。
而對於safari來說，他不是一次性請求全部文件的（不論osx還是ios），一般首先會請求0-1字節，這個寫在request header的"range"字段中：
range:'bytes=0-1'
如果是想要傳輸視頻，必須要解析range字段，然后按照range字段的要求返回對應的數據，同時response header至少要包含三個字段："Content-Type", "Content-Range", "Content-Length"
"Content-Type"必需明確指定視頻格式，有"video/mp4", "video/ogg", "video/mov"等等，網上可以查到。
"Content-Range"格式是 "bytes <start>-<end>/<total>"，其中start和end必需對應request header里的range字段，total是文件總大小，不是返回的數據長度
"Content-Length"指定返回的二進制長度
然后有幾個坑：
1.chrome有時候會一次性請求全部內容，range是這樣的 'bytes=0-'，解析的時候需要注意
2.所有的end是指inclusive end，意味着文件長度如果是245，返回"Content-Range"就是"bytes 0-244/245"，錯一點視頻就放不出來了（包括chrome）
思考為什么safari行為不一樣：
既然視頻傳輸協議就是這么規定的，當然應該按照規定的來，偷懶沒有任何借口。
但是safari之所以分多次請求也有深層次原因。比方說先請求0-1字節（其實是2個字節），返回的時候數據並不多，但是可以通過分析"Content-Range"來獲取文件總長度。然后分段請求，比如請求第一幀來渲染thumb nail等等。這樣做有個好處就是，只有當用戶點擊播放了才請求完整文件，對於PC還好，對於手機這類數據傳輸需要收費的設備來說，必須要節省流量。
另外在iphone上chrome也用的是apple提供的內核，導致他們的行為基本上一致。（這是蘋果的規定）