url 設計是 web 設計中常被忽視的東西，事實上 url 非常重要，這不僅是乙個網頁唯一的路徑，還涉及到你的站點是否乾淨，友好。本文講述 url 這個司空見慣的 web 元素中包含的大量不應為忽視的知識，準則與最佳實踐。需要注意的是 w3c 建議使用 uri 取代 url 一說。
關於 url 的一些準則
首先是與 url 有關的一些準則。
url 的最基本的使命是唯一地代表 internet 上的乙個物件，url 必須和 internet 上的物件一對一匹配。然而現實中，這很難實現，我們經常可以通過多個 url 到達同乙個頁面，比如， 和 這種情形在現代 cms 中更是比比皆是，針對這個問題，seo moz 有一篇很好的文章，講到了如何使用 canonical url 機制解決站點中的重複 url 問題。
url 應該是永久的，這就要求你在站點上線前就非常嚴謹地規劃 url。如果有一天，你不得不更改 url，一定使用 http 301 機制，告訴瀏覽器和搜尋引擎，你的那個 url 所代表的物件，已經搬遷到新位址，這個機制可以保證你舊位址所獲得 pr 不會被清零。
這是 url 設計的根本，你的 url 應該為終端使用者而設計。保持 url 友好的乙個好辦法是在保證可讀性的同時讓它盡可能短。比如 /about 就好過 /about-acme-corp-page，當然，保持簡短不能犧牲可讀性， /13d2 一類的位址短則短矣，但並不友好。如果要在 twitter， facebook 一類的社會**網路分享你的 url，可以使用 bit.ly 一類的**縮短工具，但這種工具產生的縮短 url 並不友好，在 wordpress 一類的 cms 中，可以使用 prettylink pro 或 short url plugin 一類的可控制的位址縮短外掛程式。
url 的設計切忌使用一些對使用者來說沒有意義的內容，比如資料庫的 id 號， /products/23 這樣的 url 位址對使用者是極不友好的，應當使用 /products/ballpoint-pen 一類的位址。
站點內的所有 url 必須保持一致的格式和結構，這樣可以為使用者帶來信任感，如果你必須更改 url 格式和結構，需要使用 http 301 機制。
這也是 url 一致性的乙個表現，如果你的 url 擁有很好的一致性，使用者可以根據 url 猜測別的內容的 url，假如 /events/2010/01 指向 2010 年 1 月份的日程內容，那
/events/2009/01 應當指向 2009 年 1 月的日程。
/events/2010 應當指向 2010 年全年的日程。
/events/2010/01/21 應當指向2023年1月21日的日程。
這類資訊對終端使用者是沒有意義的，卻佔了額外的空間，乙個例外是 .atom, .rss, .json 一類的特殊位址，這類位址是有特別的意義的。譯者注：在某些虛擬主機式 web 伺服器，這種做法未必現實。
www 部分並不包含任何意義，是乙個額外的負擔，不友好。可以使用 http 301 機制，將 www.domain.com 定向到 domain.com 。
url 的格式如下:
key information 部分一般代表資訊的型別或類別。modifiers 部分則屬於查詢字串範疇，它不應當代表資料結構，應當代表資料的修飾。key information 部分應當盡可能簡短，同時應當表現出一種層級關係，比如 或
google news 對新聞源有乙個有趣的要求，google 要求新聞源頁面的 url 中必須包含至少 3 位唯一的數字，因為他們會忽略年份數字，因此，應該使用乙個5位或5位以上的數字。另外，也應該提供 google news 站點地圖 。如果你想向 google 提供新聞，必須按這樣的結構提供 url，當然保持一致性，可以**性也是必需的。
url 中所有字元都應使用小寫，這更容易閱讀。
url 查詢字串中可能包含一些表示行為的元素，比如 show, delete, edit 等。非破壞性的行為可以體現在 url 中，破壞性的行為應該使用 post 。
在 url 中體現網頁標題的時候，往往會用到一些特殊字元，應當把它們轉換為 url 友好字元：
全部大寫字元換成小寫
諸如 é 一類的字元應轉換成對應的 e
空格使用短劃線代替
諸如 !, @, #, $, %, ^, &, * 一類的字元應該使用短劃線代替
雙短劃線應該使用單短劃線代替
另外，沒有必要的話，避免使用 %20 一類的 url 逃逸符。
chris shiflett 建議，可以使用一些類似句子的 url，如：
譯者補充：url 的長度上限
url 的最大長度是多少？w3c 的 http 協議 並沒有限定，然而，在實際應用中，經過試驗，不同瀏覽器和 web 伺服器有不同的約定：
ie 的 url 長度上限是 2083 位元組，其中純路徑部分不能超過 2048 位元組。
firefox 瀏覽器的位址列中超過 65536 字元後就不再顯示。
safari 瀏覽器一致測試到 80000 字元還工作得好好的。
opera 瀏覽器測試到 190000 字元的時候，還正常工作。
web 伺服器：
apache web 伺服器在接收到大約 4000 字元長的 url 時候產生 413 entity too large」 錯誤。
iis 預設接收的最大 url 是 16384 字元。
to do list設計準則
lifehacker gina trapani 的這篇 the art of the doable to do list 講述了 to do list 應用的技巧，無論用什麼gtd系統，這些技巧都是有效的。文章包含部分gtd的概念詞語，請自行鑑別。你是自己的老闆 每天的工作中，你總會處於兩種模式裡 ...
索引 設計準則
1.乙個表如果建有大量索引會影響 insert update 和 delete 語句的效能，因為在表中的資料更改時，所有索引都須進行適當的調整。另一方面，對於不需要修改資料的查詢 select 語句 大量索引有助於提高效能，因為資料庫有更多的索引可供選擇，以便確定以最快速度訪問資料的最佳方法。2.組...
索引 設計準則
1.乙個表如果建有大量索引會影響 insert update 和 delete 語句的效能，因為在表中的資料更改時，所有索引都須進行適當的調整。另一方面，對於不需要修改資料的查詢 select 語句 大量索引有助於提高效能，因為資料庫有更多的索引可供選擇，以便確定以最快速度訪問資料的最佳方法。2.組...