1樓：QueryPHP
統一 request 進和 response 出，不要die、exit等中斷後續，新增響應頭，設定響應狀態，記錄日誌等。
2樓：eechen
渲染檢視操作函式示例:
/** * 渲染檢視模板
*/ ob_start();
require $template;
return ob_get_clean();
}render返回HTML比直接輸出HTML更加靈活,因為你可能會在真正echo輸出前進行一些字串替換操作,比如敏感詞.
3樓：王賢斌
如果，你當前的這個路由返回形式並不是繫結乙個view 輸出內容的情況呢？
比如，example頁面，預設是example.html，也有可能是example.json
當然，這個只是一種針對controller的擴充套件用法。echo這個不要在伺服器端濫用，弄不好就汙染了響應結果。而且非常不好排查。
用reture不是直接返回給響應的結果，而是給他呼叫者，呼叫者可以做很多其他複雜的包裝，讓架構有更多擴充套件的餘地。
還有http 是怎麼結合伺服器端指令碼進行請求的處理，以及怎麼加工響應的內容（即request和response）要用心了解一下。這樣對研究 PHP的框架會有很大的幫助。
4樓：Ho Lee
但我不知道具體的思想，我想是看起來更方便吧，更符合OOP思想吧，返回乙個資料而不是直接echo，資料可以由系統處理，可以說安全性相對更高吧。。。
你echo出來的不一定是什麼玩意，返回給系統的，如果有安全機制的話就會更安全一點的，或是更方便，新增一些額外的配置專案也是不錯的
php開發介面系統，使用框架和原生php開發的效能和安全問題怎麼考慮？
框架和安全沒有必然聯絡。當然框架提供的庫可能會提供一些常見問題的解決方法。如果真的是5W併發，系統瓶頸也跟框架關係不大了，還要考慮頻寬，前端 儲存系統的處理能力。只要系統能有基本的可伸縮性，多幾部署個節點可以抵消框架帶來的負面影響 值不值可以根據自己的情況計算 但這樣壓力會集中到下層的儲存服務上 D...
糾結使用原生PHP還是框架
1 看老闆怎麼說。2 看修改的規模。改動小，在原來基礎上改。預期改動很大，原來的修改時間代價太高了，重做。3 可以考慮部分預期修改頻繁的頁面重做，其它的保持原狀。優先處理常用功能的優化。框架也有缺點，就是框架開發者不維護現有框架，大家都轉移到新的技術棧的時候，維護起來還不如原生的呢 yukon 學之...
有沒有不用composer的php框架？
個人自己寫的框架裡composer基本就是載入資料庫中介軟體用的，不用composer的話自己再額外寫個自動載入也行。不喜歡的話自己也寫乙個腳手架不就完了。話說不知道題主在寫php前用的什麼語言。composer和其他語言的輪子庫使用上並沒有特別大的區別 不如說這年頭誰不套輪子自己一把梭誒。 幻覺大...