背景

前臺的變更：

app3.0版本將原先在app上的簽到入口轉(zhuǎn)了h5頁面中。

后臺的變更：

簽到不再調(diào)用原先app-api模塊的接口，而是調(diào)用creditmall-api的接口，也就是說將簽到從那邊轉(zhuǎn)了過來。

數(shù)據(jù)庫：

簽到表從dbapp轉(zhuǎn)移到了dbcreditmall

產(chǎn)生的問題：

android，ios的3.0上線時間是不一樣的，積分商城簽到的上線時間與以上2個也是不一樣的。如果積分商城先上，那么會出現(xiàn)2個簽到，app＋積分商城h5。如果android/ios先上，那么會出現(xiàn)沒有簽到入口。簽到得積分的規(guī)則是每天：5.10.15.20.20.20...因為簽到表的不同，新的表是空的，所以頭3天不管用戶累計簽到了多少天，都只能從5分開始累計。而且如果以后需要統(tǒng)計簽到總的記錄時，會比較麻煩。

解決的思路

多簽到問題：

因為2個版本的客戶端，以及積分商城的h5上線時間都是不一樣的，所以出現(xiàn)2個簽到的入口時不可避免的。現(xiàn)在要避免的是：用戶一天簽到2次，其實就是往2個數(shù)據(jù)庫的2張表里插了2條數(shù)據(jù)，又分別給用戶加了積分。而我這恰好又有積分記錄明細(xì)表，可以通過這個表來判斷用戶是否簽到過了，然后h5中再決定是否讓這個按鈕失效，這樣是比較友好的。這樣做我這邊是沒有問題了，他那邊簽到完了再來我這頁面，我能夠知道他已經(jīng)簽到過了，能假裝是同一個入口。但是如果用戶是先進(jìn)的h5（我這）簽到，再去app上簽到，這就沒有辦法了，這再去修改原先簽到的判斷接口。所以第一種解決方案就是：修改簽到狀態(tài)判斷的接口。新舊2個模塊同時修改。不管新的舊的，簽到的時候都得調(diào)用積分商城service的加積分服務(wù)。如果我把上面的判斷加到了這個地方（雖然聽上去有些不合理），那么只需要修改這一個地方就行了。但是與上面不同的是：上面做的能夠使得簽到按鈕變成已簽到狀態(tài)，做到以假亂真；而這里只能做到點了簽到后不給你加分，或者是再告訴你你之前簽到過了。第一種方法比較合理，但是麻煩；第二種方法稍微簡單了一點，但是感覺不怎么合理。所以我們采用了第三種方法：不管了，，，讓他多簽到一次又何妨??！

累計簽到斷點問題

要解決這個，相比上面的問題，是要簡單的多。雖然沒有簽到記錄表可以差，但是又積分記錄明細(xì)表可以查。選擇指定用戶id，積分類型為簽到，然后再來個日期范圍，直接就查到數(shù)據(jù)，知道現(xiàn)在應(yīng)該是第幾次簽到了。所以最終的解決方案就是：前后差不了幾分，不管他了。。。。

總結(jié)

應(yīng)對多簽到問題：

新舊入口都加判斷

應(yīng)對簽到斷點問題：

沒簽到表查的時候去查積分明細(xì)表再加以分析

最終的解決方案：

不管他