初步想法：
獲取介面返回的駁回原因，不為空顯示駁回原因，空則顯示提醒輸入認證資訊，乙個if else全搞定。
實際開發：
由於駁回使用者認證資訊後，使用者再次認證是修改認證資訊，而不是新增認證資訊，即駁回原因對應的是上一次的駁回，而不是修改後對應的原因。
故前端邏輯應該修改為，駁回原因跟著審核狀態走，只有駁回狀態才有駁回的原因，其餘的都是提醒使用者輸入認證資訊。
導致問題的原因：
1.前端思考過於簡單，同時前端不了解後台資料表結構，也不了解後台邏輯；
如果後台資料表結構是，駁回原因是單獨的表，審核狀態中只有駁回的時候才關聯駁回原因表，也不存在問題；
如果後台邏輯，駁回資訊後重新認證是新增資料，就不存在問題；
2.前端經驗不足，對後台邏輯了解不足；
3.如果前後端沒有詳細溝通，實際過程中這樣的溝通也很少，仔細檢視ui圖發現：
未關聯——請輸入個人身份資訊
審核中——已在2023年4月10日提交， 耐心等待審核結果。
已認證——已完成實名認證
提示訊息跟著狀態走，而不是提示訊息跟著返回的駁回資訊走；
同時要積累經驗提示資訊肯定跟著狀態走，不一定跟著駁回資訊走；
開發過著中一定要搞清楚「跟著誰走」這個問題；
學習方法的一點提示
常聽人說計算機高手都是自學成才的，不是老師教出來的。想想也是，課堂上老師講的內容有限，而且很大一部分學生也是不感興趣的。每個人愛好不同，你愛好的未必老師就講，而且說實話很多老師水平也很有限 特別是很多沒有做過專案的老師 我們怎麼辦？我想我們能利用的資源就是網路和書籍，書籍我就不再多說了，如何利用好網...
重溫狀態模式的一點感想
今天又重溫了狀態模式，再聯合其他的一些知識點，對狀態模式有了一些新的想法，加深了理解。我覺得狀態模式非常適合於工作流中 申請 的狀態，當我們在oa中提交乙個 申請 時，這時候他的狀態是建立，然後提交到部門負責人審批，當部門負責人審批後，狀態同時改變，變成了 部門審批 接著是提交到事業部老大審批，狀態...
關於獲取網絡卡資訊的一點訊息
建議使用高版本的vs軟體進行編譯，vc6.0缺乏相應sdk，不過vs2013確實耗記憶體，不好意思說自己自己的電腦配置問題，t t include include include pragma comment lib,iphlpapi.lib int main dlretval getadapter...