首先，做下简单说明：
　　DEDECMS系统，以及DZ的HE系统如果能够完美结合，那么这两个系统都将把自身发挥到极致
　　而整合的最大关键就是获取UC的用户uid值这样在程序和用户数据的调用上都很方便了
　　在整合中出现了一些2B的问题比较棘手
　　1，DEDE不能完美的体现UC的用户ID造成无法正常的通信
　　2，UC的头像和DEDE的用户头像无法统一化一定程度上也是第一点所致
　　所以这里着重对UC的UID获得做一个解析
　　因为是按照个人的织梦dedecms建站模式叙述，所以，只谈心得，不谈具体方法
　　我使用的是UCHE注册，同步用户到DEDEweixiu3721
　　通过数据可以看出，he注册并且登陆后，DEDE中无任何数据
　　当用户首次登陆DEDE后，就会在dede_member下生成一个mid这个是按照用户登陆DEDE的顺序激活的
　　也就是说例如he注册到第10个用户，但是前9位都是只注册，没有经过dede登陆，那么当第10位登陆dede
　　就产生了uid=10 mid=1的情况，而在dede中没有直接的途径获得uc的uid
　　解决方法1：用户在uche注册后，直接跳转到dede登陆界面要求其登陆。这个比较简单，但是一旦有人不守规矩，不登陆，那么后面的人就完全错乱了。。
　　解决方法2：用户注册后直接post数据到dede请求激活，未做测试，估计也存在延时，等等问题造成混乱
　　解决方法3：也是我目前使用的方法，当用户第一次登陆dede产生mid的同时（参上上面mid的地方），也会产生一个face
　　重点就在这里了，face里面包含了一个真正的UID!
　　查找数据搜索整个文件夹找到=middle属性，这里就是face的上传数据段
　　删除前后，只保留uid
　　这样重新登陆，发现数据表中face已经完全等于uc的uid了，而可能不等于mid
　　所以在系统中涉及到uc uid的地方可以使用$cfg_ml>fields['face']进行调用
　　$cfg_ml>fields['M_id']系统原有，表示用户在DEDE的激活顺序/id
　　$cfg_ml>fields['face']修改后添加，表示整合后，在DEDE中调用UC的UID
　　两者可以并存，切存在不相等的可能性而且极大，所以根据情况使用即可
　　解决了UID问题
　　这样就可以带来很多好处
　　例如：
　　评论时显示用户头像。点击头像进入UCH的空间
　　等等这里好处肯定是很多
　　接下来进阶处理
　　UC看似开源但是在用户头像这里却是一个死胡同
　　既然我们获得了UC的UID
　　那么我们就可以进一步突破UC
　　来让两者更好的融合
　　从头像开始，把所有头像保存到DEDE目录下，使用QJ裁剪，按照UID排列
　　这样就把DEDE变成了用户的头像中心
　　而且可以自定义大小和样式
　　说明在下是DEDE和DZ的老用户所以很多棘手的问题都拿来谈谈
　　可能DZ的问题DEDE的用户不是很关系我不过是谈谈而已
　　接下来，在事件推送中
　　把评论系统加以改造
　　默认评论中评/或者其他
　　默认POST数据顶一下
　　隐藏输入框只留一个发布按钮命名为踩一脚
　　呵呵，这样
　　推送时在HE里显示
　　XXX对文章XXX踩了一脚
　　这样完美的把HE的踩日志和DEDE的评论文章伪装融合
　　那正常的评论，让用户点击进入评论独立页
　　进行评论，而推送时根据中评好评等3个类别进行分类推送
　　例如我定义的是差评默认踩一脚
　　其他的为评论推送
　　暂时先这么多吧
　　总之，完美的融合
　　以达到无缝使用
　　才是DEDECMS和UC两大主流系统的宿命啊