在基于IE多標簽瀏覽器中的偽沙箱問題就不說了，最嚴重的是cookie的問題。使用FileReference.upload的方式上傳文件，http請求中附帶的cookie信息不一定是當前瀏覽器進程的cookie，在Firefox、chrome等非IE瀏覽器中非常嚴重，可能傳輸的是IE中的cookie。即便是IE，也可能傳輸的cookie內容和當前頁面的cookie記錄不符合。這直接導致服務器端在收到文件之后的安全驗證中失敗。而對于阿里巴巴這樣的大型網站，有比較成熟的javaweb框架，要去掉對cookie的依賴非常麻煩。于是結果就是，首先我們只有在用戶使用IE系瀏覽器的時候才使用Flash上傳，其次我們隔三岔五的還會收到使用IE的某些客戶的投訴，在花費了大量的時間排查之后，我發現是由于cookie的問題導致上傳失敗。這個bug已經存在很多年，但是隨著Flash從9升級到10，許多版本過去了，問題依然沒有被解決。對于閉源的Flash，我們非常被動。

　　2.性能

 

　　相對于現今數碼相機的像素量，5MB的大小限制非常保守。但大于5M的時候，在一些低配置的電腦上，讀取文件內容的時候就會發生瀏覽器假死現象。假死很容易導致瀏覽器崩潰，所以我們采取了保守的限制——5MB。

 

　　另外一個性能消耗是將BitmapData編碼成JPEG文件的時候。Adobe提供了JPEGEncoder，但由于是Array實現的，所以性能是個問題。編碼一個2880×2880的圖片在一臺中等配置的電腦上大約需要15秒時間。

 

　　3.圖片質量

 

　　Flash內置的最好的圖片縮小算法（用BitmapData.draw，并將smoothing參數設為true），在縮小圖片的時候容易產生鋸齒。因此我改寫了Jacwright提供的縮小算法，圖片質量的問題解決，但代價是性能又降低了一些。

 

　　4.安全限制

 

　　Flash10.0之后，增加了一個安全限制——當URLLoader以標準文件上傳的方式發送POST請求的時候，需要由用戶的UI操作（鼠標點擊或按鍵事件）觸發。因為我們對用戶的圖片做了處理，已經無法再通過FileReference上傳，只能通過URLLoader。這個安全性限制規定每次發起一個上傳文件的URLLoader請求，都必須讓用戶點擊一下鼠標才可以。如果用戶選擇了20張圖片，就要點擊20次鼠標。這顯然是無法接受的。因此我們放棄了用標準文件上傳，采用普通post形式。代價是失去了對上傳進度的跟蹤，不知道文件上傳的百分比；同時服務器端也需要改造。