1. jsfor...in循環出來的對象屬性順序到底是什麼規律
首先，對於自己的屬性排序而言，遵循了特定的規則，即如果屬性是數組索引（從0到2^32-2），則按大小排序，其餘屬性則按照字元串和符號的插入順序進行排序。
然而，對於for in循環的順序，則是一個歷史遺留問題。最初設計時並未設定具體順序，直至2019年，委員會根據當時引擎的共同行為進行標准化，順序為先自己的屬性，然後上溯原型鏈，僅包含可枚舉的字元串鍵。然而，若原型鏈中包含特殊對象，如代理，或在遍歷過程中修改屬性或原型鏈行為，則順序仍為未定義，因為這些非標准情況在引擎實現上不一致且存在各種奇怪的bug。
總的來說，for in遍歷的順序標準是對實際使用習慣的記錄，對於未定義的情況則繼續處於未定義狀態。
在自己的屬性遍歷方面，實際的排序與原始意圖略有出入。按照最初設計，應該是從0到2^53-1的整數按大小排序。但由於幾個主要引擎出於優化目的，將范圍限制在了uint32范圍內（即數組索引，實際限制為長度減1）。標准委員會試圖在標准意圖與實現之間保持平衡，但ES6的主導者退休後，引擎廠商代表傾向於避免修改實現，導致目前情況。
原始設計將整數索引視為大小排序，其他屬性按插入順序排列，主要出於對原始對象設計的理解。雖然整數或數組索引都受限於人為設定的上限，但整數索引更為合理，也更不易觸及邊界。至於性能問題，無論哪種設計，優化策略都是將屬性分類存儲，本質上無根本差異。廠商曾提出實現復雜度和內存佔用增加的理由，但在我看來，這更像是逃避責任的借口。歸根結底，設計決策更多地考慮了實現者的便利。
綜上所述，JS中for in循環和own keys的排序遵循了特定規則和歷史遺留問題，理解這些規則有助於開發者更好地利用語言特性。