向大神请教的结论

其中：

const int64_t DIVIDER = HIVE_HARDFORK_1_25_MAX_OLD_GOVERNANCE_VOTE_EXPIRE_SHIFT.to_seconds();
governance_vote_expiration_ts = HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP + fc::seconds(governance_vote_expiration_ts.sec_since_epoch() % DIVIDER);

这个求余操作是为了避免到期时间集中，将其分散到一个时间窗内处理。这样做可以避免区块链性能受到影响。

唯独

#define HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP (fc::time_point_sec(HIVE_HARDFORK_1_25_TIME) + HIVE_GOVERNANCE_VOTE_EXPIRATION_PERIOD)

我们都觉得设置的有些不合理
改成如下代码就好了：

#define HARDFORK_1_25_FIRST_GOVERNANCE_VOTE_EXPIRE_TIMESTAMP (fc::time_point_sec(HIVE_HARDFORK_1_25_TIME) )

不过也没啥大不了的，一年后一切就都正常了
（感觉有点久远呢，唉）

另外还有就是：

#define HIVE_HARDFORK_1_25_MAX_OLD_GOVERNANCE_VOTE_EXPIRE_SHIFT (fc::microseconds(HIVE_GOVERNANCE_VOTE_EXPIRATION_PERIOD.count()/2))

这个值我个人觉得改成1个月就挺好，没必要用半年，毕竟一年以上没动治理票的其实应该不太多，就算有几十万个用户没动，1个月约有86W个区块产生，处理几十万用户绰绰有余了。