最初的思路：

可能會出現的問題：

1. 使用者註冊id從哪裡獲取？
   1. 可以修改使用者註冊的那個方法 註冊完後返回註冊使用者的id。

可以根據註冊使用者資訊的某一個欄位在新增成功後在查出來id）

1. 被推薦人的那個使用者表裡沒有註冊碼這個欄位，而且使用者表裡也沒有註冊碼這個欄位
   1. 可以把這個註冊嗎換成推薦人列表中的任何一個欄位 然後直接根據這個欄位查 或者直接給使用者表的推薦人id
2. 我在後臺生成的那個uuid還需要嗎？
   1. 渠道表裡線上下都已經生成了。

更改後的思路：

表的結構不變，邏輯變了一點，首先渠道表線上下生成後會有一個對應的渠道標識，使用者註冊時，只是在中間表上加了一個記錄，這個中間表的作用時把渠道和使用者的名稱對應起來，日後如果使用者確實是因為該渠道註冊來的，直接查詢中間表把該渠道查出來進行我們的業務操作，至於推薦人，直接後臺寫死，而中間表中的渠道人這個欄位也沒有用。

出現的問題1：

首先就是傳值問題，一定要注意是post請求還是get請求，看清之前沒有加推廣邏輯時傳的是什麼值，如果直接在連線上拼接，肯定是要用到Httpservletrequest的，我用postman測試傳過來的值始終獲取不到，後來問了一些人，因為我們專案中的登陸註冊適合並在一起的，不管登陸還是註冊都是走的同一個介面，如果登陸不上，在這個介面中呼叫註冊的方法，這就需要在登陸中就把引數傳過去，然後再傳給註冊的方法，進行一個註冊的邏輯，

Service中也要加一點邏輯：

Linux報的錯：