說個最簡單的例子吧，我以前做項目的時候發現一個優化點，很高興的跟組長溝通，組長卻很生氣，說沒有提需求的時候不要亂改，改好了別人未必會夸你，但因為你的修改導致出了bug那你就是千古罪人。這種事在越大的項目里面越可能出現，長時間大量不同人的代碼累積，導致很難縱觀全局，屬于是事不關己高高掛起，畢竟都是打工人而已。

這個有個bug

window記事本目的就是瀏覽所有文字，不是為了看小說而開發的，他需要具有通用性，做程序員的都知道有時候一個文件很大，我想找到我需要的代碼，需要搜索，那么搜索的話就需要加載全部文本，所以這個一次性加載是必要的，因為你不知道使用者會用他來干嘛。但是你的那個看小說的，他的目的就是一個，看小說。如果你知道一個小說里面有一句話，想知道他在哪兒，那你會用那個什么文曲星軟件去搜嗎？你用這個軟件就一個功能看小說，不會有人看小說的速度能夠快過電腦的讀取速度，所以你可以針對性的優化某一個方面，比如動態加載！所以用記事本和那個文曲星的軟件沒有對比性，但是大廠的一些軟件做的的確拉。

記事本在搜索時要重新讀一遍文本

所以打開時讀沒讀無所謂，像這種32m的文本用emeditor或者其他專業的文本編輯器（不是vscode和ide）都能秒開秒搜。只是記事本在開發時就沒有賦予編輯大文本的需求，他只是個notepad而已，又不是專業的text editor。mb以下大小的文本才是它的處理范圍。

其實記事本打開大文本慢并不是記事本程序本身的問題，而是標準編輯框控件的問題。Windows的標準控件有很多逆天的地方，做過Windows開發的應該體驗過（比如listbox的平滑滾動，還有莫名其妙的自定義繪制）。