1樓：和菜頭
重新設計也解決不了這個痼疾。
唯一ID對於小眾社群是有效的，但是使用者人數稍微多一點，許多名字因為重名就不能用了，只能加長。加長或者變形的結果，是讓朋友很難找到自己，找到了也很難記住。所以，又弄出了可以相同的暱稱，用作身份甄別。
這不是豆瓣一家的問題，對於使用者數過千萬的社群，大多都會出現類似困境。
而對於使用者來說，不能用自己的名字，或者喜歡的ID，是非常不愉快的體驗。
2樓：
據我所知：豆瓣上有太多的感覺糾葛了，所以很多使用者選擇修改暱稱，讓別人認不出來。這給其他使用者造成了識別困擾，不知道是不是提了反饋，於是豆瓣就出了這個限制。
而那些想通過修改暱稱讓別人認識不出來的使用者，後來就紛紛[已登出]了哈
3樓：風鈴子
這裡有2個問題, 1: 暱稱/ID/個性username 的系統邏輯和使用者感知; 2: 社群裡面對於暱稱(名號)的修改規則.
讓你感覺糾結的是第2點. 這個涉及不到重新設計如何如何, 因為這個取決於乙個社群對於使用者暱稱修改規則的制定. 匿名社群裡面, 暱稱(名號)是可重複的, 使用者應該可以修改的, 同時需考慮的是簽名檔, 使用者簽名檔是又乙個常用來表現個性化的文字.
那麼社群可以自己去考慮, 鼓勵名號不動, 簽名檔變化, 還是簽名檔沒什麼作用, 名號可以隨意變化?
這個與系統設計無關, 與社群運營規則有關.
至於第1點, 目前豆瓣裡面ID是系統數字, 使用者沒有感知, 設計上也不需要使用者感知. 暱稱的設計就是使用者在匿名社群裡面的"姓名", 使用者習慣稱謂自己的也是這個, 無論是系統設計還是UE設計, 都要明確突出名號, UE上你要鼓勵的也是這個.
而個性username, 一部分取決於社群裡使用者個人主頁的作用, 使用者對於自己的mine頁面是如何感知的, 想要如何使用, 如果很強化"個人空間", 那麼個性化username是使用者需求上常規看重的, UE設計上就可以加強鼓勵.
btw, PM會提出這樣的問題, 但可能使用者知道的就是暱稱(名號), 另外乙個使用者知道的是自己的登入email. 需要圍繞使用者感知的東西來考慮UE的設計.
(被提醒過來回答, 不一定很全, 以後可能補充修改)
4樓：吳超
這個是在社群產品設計的時候必然會碰到的問題，這個修改其實還與該使用者的歷史動作以哪個名字展示有關，常有幾種情況：
1、隨意修改名字；歷史動作展示當時動作發生時使用的名字（最好能記錄每次修改，在user detail page展示）；
2、隨意修改名字；歷史動作展示最新使用的名字；
3、限定修改時限或禁止修改；歷史動作展示最新使用的名字；
4、……
1更符合現實社會的邏輯，但可能導致使用者識別困難（因為與現實社會不同的是使用者的頭像可隨意更改）。
2容易產生混亂，導致使用者識別困難，而且對於自然人社交網路可能會讓使用者對自己的行為不付責任。
3各方都有所兼顧，折中效果
GA如何抓取使用者名稱資訊？
微風詩雨 跟user id 一樣的邏輯，作為乙個全域性變數，gtm裡用一段js去讀取轉成緯度，到時就可以任意交叉查詢了。不足的地方是緯度數量有限 還可以將使用者資訊用使用者資訊做簡單加密後用get的形式傳送資料，再用gtm讀取page url，解密，轉成緯度 tjefferson 設定乙個自定義維度...
為什麼 QQ 用數字作為使用者名稱？
因為加QQ的時候可以只報一串數字就好，你說我加。我覺得是現有qq我才知道的郵箱的，第一次使用郵箱就是qq郵箱。本來就是這個設定，天經地義，初始的代入觀念已經我改變。我答應小表弟，只要你期末考試夠考80分，哥就給你申請個qq號。 lein 這是乙個很好的問題，從一名普通的使用者角度，個人認為用數字作為...
linux使用者名稱和組名可以相同嗎？
事過境遷 可以相同。使用者組是具有相同特徵使用者的邏輯集合。即可以讓多個使用者具有相同的許可權，比如 檢視 修改檔案的許可權等。使用者名稱和組名相同的例子，最具有代表性的則是root使用者，root使用者是的屬組就是root組。在建立新使用者時，預設的屬組即和使用者名稱相同，比如建立乙個test使用...