一般在系统中使用cityId来表示城市信息。

城市id生成

1、强制 用户/商家/骑手的cityId初始化时，统一通过一个服务来生成。cityId底层由地图服务定义，cityid一般=国家前缀+城市编号。

保证city信息收敛、计算正确

城市可以通过用户手机定位来获取，也可以让用户从支持的国家城市列表中选择国家和城市。

（1）后端：国家/城市（统一称为区域）生成规则

业务实体	区域属性	区域属性来源	备注
门店	城市	门店入驻时选择的城市（经纬度获取或商家手动选择）
用户	国家	用户注册时选择的国家
骑手	城市	骑手注册时选择的工作城市
用户订单	城市	下单门店的城市	跨城订单怎么办？
商家订单	城市	下单门店的城市
骑手配送任务	城市	下单门店的城市
客户	国家	客户注册时选择的国家

（2）前端：国家和城市生成规则

APP	获取逻辑
C用户端	用户在首页自动定位或通过地图拖动，根据经纬度从后端获取国家和城市 如果后端返回为空，则让用户从支持的国家城市列表选择一个
B商家端	商家登录前：商家选择国家，从后端拿首都。 登录后：选择门店，设置为门店的国家和城市
D骑手端	登录前：骑手选择国家和城市 登录后：从后端拿骑手注册的国家和城市
M(BD APP)	首次启动后，进行选择选择国家和城市，然后缓存

2、建议业务开展国家、城市列表需要分业务、分端、分场景下发。

比如出行业务、外卖业务、金融业务、差旅业务开展的国家、城市不同；

外卖业务内，要先招募商家、再招募骑手，最后对用户开放，所以BCD端开国开城列表也不一样。

城市id传递

1、建议 cityId为了保证正确，可以在参数中显示传递给下游。

1、建议 cityId可以放在网络通参中进行全链路传递，前端放在http header中，后端放在trace中。

方便业务获取城市信息，做逻辑处理

城市id存储

1、强制 核心实体（门店、骑手、用户订单、商家订单、骑手配送任务）的库表需要增加city_id，字段类型是bigint。

不同城市时区不一样，保存了城市才能拿到时区，时间才能计算展示正确。如订单时间、活动时间。

城市id使用

1、 建议 优先从业务数据实体中获取cityId，没有再用通参中的cityId。

用户端：从订单获取cityId。

商家端：从订单获取cityId，没订单用门店的cityId。

骑手端：从运单获取cityId，没运单用骑手工作cityId。

司机端：从订单获取cityId，没订单用司机工作cityId。