如果你以为钉钉小程序和微信小程序只是“换了个壳”的同类产品后面踩坑会踩到你怀疑人生。这两个东西虽然都叫小程序但底层的设计逻辑、生态边界、账号体系、能力开放方式基本是两套平行世界。简单说微信小程序是围着C端用户的流量、传播和消费体验转的钉钉小程序是围着企业组织、审批流程、内部协同转的。这个差异不只是代码写起来不同而是从产品方案设计那一刻起你就得做出完全不同的取舍。这篇文章适合正在做小程序平台选型的开发者想在企业内部快速搭应用的IT人员以及需要同时维护微信和钉钉两套小程序的团队。我会尽量不复制粘贴官方文档里那些你已经能搜到的话而是把两边在真实项目里的差异点、坑点和取舍逻辑讲透。毕竟文档告诉你接口长什么样但不会告诉你哪些地方一群人白白加班了两周。1. 两个小程序的本质区别入口、账号与生态定位1.1 入口路径和用户心智完全不同微信小程序的核心词是流量和场景融入。用户从聊天列表下拉、扫一扫、搜一搜、朋友分享的小卡片里进来绝大多数人跟你没有任何信任关系就是一个路人。你要在很短的时间内让他完成注册、登录、授权、然后下单或者留下联系方式整个过程必须足够轻、足够顺。钉钉小程序的入口完全相反。用户是在企业工作台里看到一个应用图标点进来的时候身份已经绑定了组织这个人在哪个部门、什么职位、汇报关系是什么后台都能拿到。应用要做的是把工作流搬到线上比如报销审批、访客登记、设备报修、周报提交。用户的心智是“我来办事的”不是你求着他来用的。所以第一个要认清的事情是微信小程序做的是增量流量钉钉小程序做的是存量组织。你在微信里花大量精力做的拉新、分销、分享得利设计放到钉钉里大概率会显得很怪你在钉钉里精心设计的部门权限、审批流转、数据隔离放到微信里用户根本感知不到。1.2 账号体系差异是第一个分水岭微信小程序里的用户身份是典型的互联网用户体系。通过 wx.login 拿到一个临时 code后端拿去换 openid 和 session_key。openid 对每个小程序是唯一的同一个用户在不同小程序里 openid 不一样如果想要跨应用识别得靠 unionid。拿用户的手机号需要用户主动授权拿头像昵称在新版本规则下也有各种限制。这意味着你做微信小程序时几乎一定要设计自己的用户注册、登录、绑定流程至少在第一次进入时需要引导。钉钉小程序里用户身份天然就是企业身份。前端通过免登接口拿到 authCode后端拿 authCode 换取 userId然后可以直接调用通讯录接口拿到这个人的部门、职位、直属上级。比如员工用钉钉打开报销应用应用直接就知道他是财务部还是销售部根本不需要输入工号或者选择部门。这个差异带来的连锁反应是微信小程序开发重心有很大一块在“用户从陌生到转化的闭环”钉钉小程序开发重心在“组织内不同角色对同一数据的可见范围和处理权限”。如果你两套都要做登录态必须在服务端做映射和隔离别把 openid 当成 userId 用也别拿钉钉的 userId 去配对微信用户。1.3 分发逻辑社交裂变与内部运营是两条路线微信小程序天生适合传播。页面可以带参数分享给微信好友和群配合二维码海报可以做到一个用户进来再带三个用户进来。支付、卡券、订阅消息又把这个链路补得非常完整。做零售、餐饮预约、内容付费、在线咨询微信生态的优势非常明显。钉钉小程序更适合做内部运营和任务驱动。应用可以出现在工作台也可以以 IM 卡片、DING 消息的形式推送给指定群和指定人。比如某项审批需要三个部门会签应用直接把待办卡片推到每个相关负责人的钉钉聊天里点进去就能处理。这种“把任务推到人面前”的能力组织协同效率很高但你想靠它在公域拉新基本不太现实。我给一个比较实在的建议做产品选型的时候先别问“哪个平台开发方便”先问你到底要连接什么人。连接陌生消费者微信是几乎唯一的选择连接企业内部员工和合作伙伴钉钉的先天优势很大。对比维度微信小程序钉钉小程序核心场景C端消费、营销、服务B端办公、流程、协同用户画像陌生人为主需转化组织内员工身份明确账号体系openid/unionid需自建用户体系userId组织架构天然实名分发方式聊天分享、扫码、搜一搜工作台、IM卡片、DING典型能力支付、卡券、分享、位置审批、考勤、通讯录、日程2. 开发侧差异API体系、登录鉴权与工具链2.1 代码长得像API却是一个平行世界从代码结构上看两边确实非常像。都是页面 组件 全局配置的套路模板语法也相近甚至很多小程序开发者刚上手另一边时会觉得“这我熟”。但真写起来你会发现 API 前缀完全不同微信是 wx.xxx钉钉是 dd.xxx。比如网络请求微信用 wx.request钉钉用 dd.request轻提示一个叫 wx.showToast另一个叫 dd.showToast。看着对应关系简单但坑在于不是每个接口都能一一对应。我迁移过一个内部工具微信里用了 wx.getUserProfile 拿用户资料到了钉钉这套完全不存在钉钉里想用 dd.biz.contact.choose 直接弹出组织通讯录选人微信里也没有这种能力只能自己做一个搜索员工的页面。还有蓝牙、NFC、Wi-Fi 这类硬件能力微信封装得更多更细钉钉的开放重点则在办公场景上。你要是把所有 API 抽象成“微信有的钉钉不一定有钉钉有的微信一定没有”心态会平和很多。实际操作上我的习惯是建一个 platform.js 适配层把所有平台相关的调用收口到同一个文件里。头文件判断当前环境可以用“是否定义了 dd 全局对象”来区分然后在里面分别实现登录、请求、提示、选择联系人、获取定位等统一方法。业务页面只调用适配层暴露的方法不要在业务代码里到处写 if (dd) / else。const env typeof dd ! undefined ? dd : wx; const api env dd ? dd : wx; function showToast(title) { api.showToast({ title }); } module.exports { env, showToast, };2.2 登录与鉴权从用户中心到组织中心微信登录的标准链路是前端 wx.login 拿 code后端拿 code 到自己服务器换取 openid然后签发自定义登录态比如 token。后续请求都带这个 token。前端还需要引导用户授权手机号保存用户资料到自己的用户表整个过程跟传统的“App 注册登录”没有本质区别。钉钉的免登链路更短前端 dd.runtime.permission.requestAuthCode 拿 authCode 再交给后端后端拿 authCode 调钉钉服务端接口换取 userId。拿到 userId 后可以直接查询用户在组织里的部门、职位、工号等信息。免登的意思就是员工不需要额外输入企业账号和密码直接用钉钉的身份进入应用。// 微信侧登录 function loginWx() { return new Promise((resolve) { wx.login({ success: (res) resolve(res.code), }); }); } // 钉钉侧免登 function loginDd() { return new Promise((resolve) { dd.runtime.permission.requestAuthCode({ corpId: yourCorpId, onSuccess: (info) resolve(info.authCode), }); }); } function login() { return env dd ? loginDd() : loginWx(); }这里特别提醒一下钉钉免登能不能调通很大程度上取决于应用后台的权限配置。你需要在钉钉开放平台后台配置应用的服务器出口 IP、授权范围、以及“通讯录权限”等接口权限。我踩过最典型的一个坑是后端调用户信息接口一直返回没有权限前端免登却一切正常。查了半天发现是应用的通讯录权限没有申请同事账号根本不在授权范围内。另一个坑是 authCode 是一次性的而且有效期很短后端拿到必须马上使用不能存到库里下次再用。2.3 企业级能力审批、考勤、消息推送的差距钉钉小程序一个突出的优势是它和钉钉办公套件深度打通。你可以直接创建审批实例把费用报销、请假、用章申请等流程接到钉钉原生审批流里可以读取考勤打卡结果做迟到早退统计看板可以创建日程和会议提醒还可以通过工作通知接口向组织内特定用户或部门发送应用程序的通知卡片。这些能力微信基本都没有对应物。微信的订阅消息虽然也能触达用户但每次都要用户主动订阅而且授权一次只能推送一次根本不适合做成“审批待办提醒”这种高频场景。微信的位置、蓝牙、支付、卡券、快递地址能力很丰富适合做线下到店、电商交易、营销活动这类C端业务。所以你在画技术方案时不要试图在两个平台上追求功能完全对等。先想清楚核心业务流程长在哪个生态里。比如一个销售拜访应用核心是记录客户、提交拜访计划、让主管审批那钉钉天然合适审批和待办通知都是现成的。如果核心是用户在线下单、支付、查物流那微信是必须做的钉钉那一套办公能力帮不上忙。2.4 调试与工具链模拟器、真机、权限角色微信开发者工具和钉钉开发者工具整体都很成熟都支持代码编辑、编译预览、真机调试、日志查看。但两边有一个很不一样的调试心态微信里你要模拟的是各种不同类型、不同来源的陌生用户钉钉里你要重点验证的是不同组织角色的权限表现。比如同样一个报修应用普通员工登录看到的是“我要报修”部门主管看到的是“我下属的报修单”维修工看到的是“待接单列表”。微信开发者工具里你要手动切用户身份模拟普通用户、付费用户、企业用户钉钉工具里配合后台的角色配置真机扫码预览时切换不同账号能看到完全不同的页面和数据范围。两个工具的编译模式都支持自定义启动页面和参数这在实际开发里非常有用建议把不同角色、不同参数的入口都做成编译模式预设省得每次调试都手动扫码进入深级页面。此外真机调试时要注意钉钉很多API依赖特定客户端版本开发文档里的“最低支持版本”不是随便写的低版本钉钉上调用会直接报错或者静默失败这两个平台都是如此但钉钉由于需要跟组织管理员客户端版本绑定问题会更棘手。3. 界面规范与交互设计C端体验与B端效率之争3.1 视觉风格与信息密度微信小程序的设计规范是奔着转化率去的。页面要克制按钮要清晰每一步操作都不能让用户犹豫整体视觉风格更强调轻量、留白、品牌感。你会发现微信小程序里大量使用卡片式布局、大标题、大按钮因为消费场景里用户是“逛”的心态视觉上的引导很重要。钉钉小程序的设计倾向是信息密度高、任务导向。工作台本身就是一堆工具入口应用内部常见的形态是列表、筛选器、状态标签、批量操作按钮。一个审批列表页恨不得一屏展示更多的单据和状态因为员工每天打开这个页面的目的是处理任务不是在欣赏设计。这就引出一个很实际的问题同一个设计稿很难两端通用。我有一次把微信端的视觉规范硬套到钉钉端结果页面在钉钉里显得太“空”一个屏幕只能看到两条数据操作效率很低反过来把钉钉的列表密度套到微信端又被吐槽像后台管理系统。两边的设计规范都是无数产品沉淀出来的最优解建议遵守不要强行统一。3.2 导航、安全区与自定义头部导航和顶部安全区是容易被忽略、但是最容易翻车的点。微信小程序的默认导航栏高度、胶囊按钮的位置很多开发者已经形成肌肉记忆。钉钉客户端的结构不一样顶部可能有工作台返回入口自定义导航栏时如果直接照搬微信的顶部高度计算大概率会出现标题顶到状态栏、胶囊遮挡操作按钮的情况。我的建议是能用默认导航栏就尽量用默认导航栏省掉大量适配工作。如果业务确实需要自定义头部不要写死状态栏高度和导航栏高度要分别读取两边的系统信息接口动态计算。钉钉侧还需要考虑不同版本客户端的差异有条件的团队做一到两款主流机型的真机适配检查。另外要注意返回逻辑。微信小程序页面栈返回时遵循标准的栈规则用户从分享卡片进入时可能没有上一页需要设计返回首页的兜底。钉钉小程序嵌在组织客户端内页面返回还涉及从工作台进入的场景这时候“返回”到底返回到工作台还是上一个页面产品上要提前定清楚技术上最好在 onShow 里做一次路由状态检查。3.3 分享、DING与消息触达微信的能力重点是分享和传播。小程序可以带参数分享给单个好友或群结合海报、扫码非常利于社交裂变。在微信生态里分享不是一个附加功能而是业务增长的主要杠杆很多运营玩法都围绕分享展开。钉钉的触达体系是消息驱动。工作通知、群机器人、DING消息、日程提醒这些都服务于“把任务准确推到该处理的人面前”。比如一个请假审批申请人提交后系统通过工作通知推送给审批人审批人点卡片直接进入小程序详情页完成审批再自动通知申请人结果。这个闭环在微信里很难做得这么顺畅因为订阅消息需要用户反复授权而且授权一次只能发一次不适合做有状态的流程推送。如果你要在钉钉里做群分享可以带上业务参数同事在群里点开卡片直接定位到具体单据这是很好的体验。但我建议分享按钮的位置和触发条件要想清楚内部系统里的分享是“有目的的传递”不像微信那样是“随手的转发”不要做一键分享到所有群的泛传播。4. 场景适配与双端同构方案4.1 内部工具选钉钉外部获客选微信大多数团队会问我到底该做哪一端我的判断标准很简单核心用户是谁。用户是员工、供应商、渠道伙伴需要通过组织身份协作选钉钉。用户是消费者、潜在客户、公域流量选微信。举两个例子方便理解。一个场景是设备报修。如果只做微信小程序你得自己维护用户注册登录还要设计两种角色报修人和维修工并且要让工人能看到分配给自己的工单门店管理员能看到所有工单这些权限体系全部从零搭建。如果做钉钉小程序员工本身就是组织成员组织架构自带部门层级人员离职入职自动同步审批流还能挂到钉钉原生审批后台开发量能省一大截。另一个场景是连锁门店的点单小程序。用户是消费者他们不会为了喝杯奶茶去下载钉钉所以必须做微信小程序。扫码、小程序码、社交分享、支付闭环微信把整个消费者路径都铺好了。这时候做钉钉端意义就不大。4.2 双端同构的技术落地策略如果业务确实要求微信和钉钉两端都要上我不建议你并行开发两套代码。更合理的策略是核心业务逻辑复用平台差异隔离。具体做法可以分成三层业务层页面数据、交互状态、表单逻辑尽量写成一整套与平台无关的模块只在页面层做差异布局。适配层所有平台能力调用收口到同一个文件导出统一的 login、request、toast、chooseContact、navigateTo 等方法内部根据环境分发到 wx 或 dd。服务端登录态做统一映射不管你从哪端进来最终服务端都产生一个统一的 user 对象内部再区分 userType 是 external 还是 internal。这里要特别强调服务端的用户模型不能偷懒。同一个真实用户可能在微信端是消费者在钉钉端是员工两边 userId 不一样。如果你不做映射后续做数据打通时会产生大量脏数据。建议在 user 表上增加 platform 和 platformUserId 字段同时留一个 bizUserId 作为业务唯一标识。包体大小也需要注意。两端的静态资源限制都比较严格项目里大量使用本地大图是走不通的要养成图片走 CDN、组件按需加载、路由懒加载的习惯。如果项目一开始就是按双端同构来设计的尽量把公共组件放到独立目录避免两端各自复制代码否则后续修一个 bug 要改两遍。5. 发布审核、灰度与版本管理5.1 静态资源、分包与启动性能微信小程序对主包有严格的体积限制普通小程序的资源超了就必须用分包策略把低频页面、独立业务模块拆到分包里否则上传代码那一步就会被拦下来。钉钉小程序同样有包体限制做企业内部应用时不光是审查严不严的问题是钉钉客户端在弱网环境下加载大包体应用的体验会非常差员工在工厂里打开应用一直转圈这个应用基本就废了。包体优化的几个标准动作是大图片压缩成 WebP 并从代码包里移除、公共库抽成独立 vendor、页面按需注册组件、不打包后端模板文件。还有一个容易忽略的坑是不要把所有页面都写在 app.json 里然后全量加载钉钉和微信都支持按需注入配置不合理会导致启动页面白屏时间变长。5.2 审核规则与上架流程差异微信小程序的发布要经过微信公众平台的审核类目资质、隐私政策、内容安全都要过一遍审核不过的常见原因包括缺少用户隐私保护指引、类目与内容不符、诱导分享等。现在微信对隐私合规的检查很严格代码里有任何读取用户信息却没有在后台声明对应接口的行为都可能在提审时被打回。钉钉小程序的上架分两种场景。一种是发布到钉钉应用市场这种审核也比较严格需要提交应用截图、功能说明、隐私合规等材料另一种是作为企业内部应用发布到自己的工作台审批权在企业管理员手上更多是走内部合规流程。内部应用通常不需要面对外部应用市场那么复杂的审核但安全合规的要求依然存在比如服务器的数据存储位置、日志留存、账号权限管理企业在自测时要想清楚。5.3 灰度发布与回滚策略微信小程序有版本管理后台可以设置体验版通过体验版二维码给团队成员测试再提交正式版发布。发布后如果要紧急回滚可以在后台把线上版本切换到上一个已发布版本生效速度很快。钉钉的企业内部应用发布相对灵活但同样建议做灰度。比较稳妥的做法是先在公司内部一个小部门范围内试运行确认无问题后再全员开放。不要一上来就把所有页面、所有操作开放给全员一旦某个权限配置有误全体员工都会看到不该看的数据这个风险在内部系统里比外部产品更严重。版本缓存也是一个很常见的坑。小程序发布新版本后用户不一定立即拿到微信侧会在用户冷启动时检查更新钉钉侧对已打开过的应用也有缓存。如果服务端接口做了不兼容升级老版本前端调用新接口可能会报错建议在小程序启动时主动调用更新管理接口做静默更新必要时通过线上配置做强制版本升级。6. 踩坑实录常见问题与排查对照6.1 域名白名单和HTTPS校验两个平台都要求前端请求的接口域名配置到后台白名单并且强制 HTTPS不支持 IP 直连和自定义端口。开发模式下可以不校验域名但一上线就全盘报错。排查建议按这个顺序来先看后台白名单里有没有配这个域名再看域名证书链是否完整最后用浏览器直接访问接口看是否有证书问题或重定向。常见的情况是后台配的域名是 abc.example.com代码里请求的却是 www.abc.example.com差一个子域都算不合法。另一个坑是接口里带了非标准端口比如 https://api.example.com:8443这两个平台基本都不支持运维在配置网关时要把端口隐藏掉。6.2 用户信息获取与授权策略微信侧获取用户头像昵称的规则改过好几轮现在很多场景不建议强制用户授权而是用默认头像昵称加“点击修改”的方式等用户主动触发时才拉起授权弹窗。如果一进页面就弹授权被拒绝后后续再弹会非常困难。钉钉侧获取用户信息主要靠后端接口不需要前端弹窗授权。但应用必须具备对应的通讯录权限范围否则后端接口返回无权限。前面已经说过这里再强调一遍如果用户信息接口报了“Insufficient Permissions”或类似错误先去开放平台后台确认权限范围再看服务器出口 IP 是否配置。切勿以为是前端代码问题不然会浪费很多时间。6.3 自定义导航和页面栈问题自定义导航栏是问题重灾区。两端的胶囊按钮、系统返回按钮位置都不同直接沿用微信那套顶部布局算法到钉钉里基本都会出现错位。如果非要做自定义头部建议动态获取顶部安全区域和胶囊位置再计算导航栏高度不要使用固定 64pt 或者 88rpx 这种魔法数字。页面栈问题也同样容易被忽略。微信小程序从外部 share 卡片进入时没有上一页按返回键会直接退出小程序这时需要自己判断页面栈深度并兜底跳转到首页。钉钉里从工作台进入应用和从 IM 卡片进入应用页面栈初始状态不一样如果代码里默认页面栈里一定有上一层会出现返回地址异常。6.4 登录态过期与多身份切换钉钉小程序里同一个设备可能在不同企业组织之间切换或者同一个员工从 A 企业调到 B 企业。切换组织后之前应用里缓存的登录态理论上已经失效但很多代码不会自动感知用户还停在旧的业务页面上操作就会出现接口报错或者看到别的组织数据。我建议你在小程序 onShow 的时候主动校验一次身份状态前端发现用户身份发生变化时清理本地缓存并触发重新登录。后端接口也要在关键操作上做组织ID校验不能只信任前端传来的参数。微信侧没有组织切换问题但用户可能在小程序间跳转登录态过期一样要处理请求返回 401 时统一拦截并跳转到登录页。6.5 模拟器正常真机异常这是所有小程序开发都会遇到的问题。模拟器里跑得好好的真机一打开就白屏、接口报错、样式错乱。常见原因无非是域名校验、客户端版本兼容、以及真机网络环境不同。此外开发者工具默认关闭了很多安全校验真机上这些校验全部生效所以“模拟器正常”根本不代表代码没毛病。一个比较稳妥的做法是准备一台专门的测试手机每次提测前至少跑一遍核心链路登录、进入首页、发起一个完整业务流程、退出登录。同时要留意两端客户端的版本差异钉钉很多API要求客户端不低于某个版本员工手机上的钉钉版本过旧会导致功能不可用。这种情况在微信侧也存在但钉钉的企业环境里员工客户端版本分布更难控制必要时可以在应用里做一个版本检测和升级引导。某个项目组曾经在两套小程序里同步复用一个业务组件改 bug 时只改了微信侧钉钉侧漏了一处结果上线后钉钉用户直接无法提交表单。从那以后我们定了规矩任何公共代码的修改两端的回归测试必须同步跑谁也不能只测一边就宣布提测完成。双端开发最难受的一点就是你以为你在写一份代码实际你在维护两个生态习惯完全不同的应用。这个感受不亲自做一遍很难体会。如果想省心选型阶段就要坚决一点内部协同场景锁定钉钉消费者场景锁定微信。两套都做时也务必把平台差异收口在适配层让业务代码尽量保持干净。最后分享一个小技巧。我习惯在项目里用一个统一的环境判断文件里面不只区分微信和钉钉还会区分开发者工具、真机预览、正式版环境。平时进页面时把环境信息打印在调试日志里排查问题的速度快很多。这些细节看着不起眼在团队协作时能帮你减少大量“我这正常啊”的扯皮时间。两种小程序各有各的道想清楚到底要干什么比纠结选哪家更重要。 
长河君 · 2026/10/21 7:54:56 · 阅读 1.2k 微信小程序与钉钉小程序：核心差异与双端开发避坑指南
如果你以为钉钉小程序和微信小程序只是“换了个壳”的同类产品后面踩坑会踩到你怀疑人生。这两个东西虽然都叫小程序但底层的设计逻辑、生态边界、账号体系、能力开放方式基本是两套平行世界。简单说微信小程序是围着C端用户的流量、传播和消费体验转的钉钉小程序是围着企业组织、审批流程、内部协同转的。这个差异不只是代码写起来不同而是从产品方案设计那一刻起你就得做出完全不同的取舍。这篇文章适合正在做小程序平台选型的开发者想在企业内部快速搭应用的IT人员以及需要同时维护微信和钉钉两套小程序的团队。我会尽量不复制粘贴官方文档里那些你已经能搜到的话而是把两边在真实项目里的差异点、坑点和取舍逻辑讲透。毕竟文档告诉你接口长什么样但不会告诉你哪些地方一群人白白加班了两周。1. 两个小程序的本质区别入口、账号与生态定位1.1 入口路径和用户心智完全不同微信小程序的核心词是流量和场景融入。用户从聊天列表下拉、扫一扫、搜一搜、朋友分享的小卡片里进来绝大多数人跟你没有任何信任关系就是一个路人。你要在很短的时间内让他完成注册、登录、授权、然后下单或者留下联系方式整个过程必须足够轻、足够顺。钉钉小程序的入口完全相反。用户是在企业工作台里看到一个应用图标点进来的时候身份已经绑定了组织这个人在哪个部门、什么职位、汇报关系是什么后台都能拿到。应用要做的是把工作流搬到线上比如报销审批、访客登记、设备报修、周报提交。用户的心智是“我来办事的”不是你求着他来用的。所以第一个要认清的事情是微信小程序做的是增量流量钉钉小程序做的是存量组织。你在微信里花大量精力做的拉新、分销、分享得利设计放到钉钉里大概率会显得很怪你在钉钉里精心设计的部门权限、审批流转、数据隔离放到微信里用户根本感知不到。1.2 账号体系差异是第一个分水岭微信小程序里的用户身份是典型的互联网用户体系。通过 wx.login 拿到一个临时 code后端拿去换 openid 和 session_key。openid 对每个小程序是唯一的同一个用户在不同小程序里 openid 不一样如果想要跨应用识别得靠 unionid。拿用户的手机号需要用户主动授权拿头像昵称在新版本规则下也有各种限制。这意味着你做微信小程序时几乎一定要设计自己的用户注册、登录、绑定流程至少在第一次进入时需要引导。钉钉小程序里用户身份天然就是企业身份。前端通过免登接口拿到 authCode后端拿 authCode 换取 userId然后可以直接调用通讯录接口拿到这个人的部门、职位、直属上级。比如员工用钉钉打开报销应用应用直接就知道他是财务部还是销售部根本不需要输入工号或者选择部门。这个差异带来的连锁反应是微信小程序开发重心有很大一块在“用户从陌生到转化的闭环”钉钉小程序开发重心在“组织内不同角色对同一数据的可见范围和处理权限”。如果你两套都要做登录态必须在服务端做映射和隔离别把 openid 当成 userId 用也别拿钉钉的 userId 去配对微信用户。1.3 分发逻辑社交裂变与内部运营是两条路线微信小程序天生适合传播。页面可以带参数分享给微信好友和群配合二维码海报可以做到一个用户进来再带三个用户进来。支付、卡券、订阅消息又把这个链路补得非常完整。做零售、餐饮预约、内容付费、在线咨询微信生态的优势非常明显。钉钉小程序更适合做内部运营和任务驱动。应用可以出现在工作台也可以以 IM 卡片、DING 消息的形式推送给指定群和指定人。比如某项审批需要三个部门会签应用直接把待办卡片推到每个相关负责人的钉钉聊天里点进去就能处理。这种“把任务推到人面前”的能力组织协同效率很高但你想靠它在公域拉新基本不太现实。我给一个比较实在的建议做产品选型的时候先别问“哪个平台开发方便”先问你到底要连接什么人。连接陌生消费者微信是几乎唯一的选择连接企业内部员工和合作伙伴钉钉的先天优势很大。对比维度微信小程序钉钉小程序核心场景C端消费、营销、服务B端办公、流程、协同用户画像陌生人为主需转化组织内员工身份明确账号体系openid/unionid需自建用户体系userId组织架构天然实名分发方式聊天分享、扫码、搜一搜工作台、IM卡片、DING典型能力支付、卡券、分享、位置审批、考勤、通讯录、日程2. 开发侧差异API体系、登录鉴权与工具链2.1 代码长得像API却是一个平行世界从代码结构上看两边确实非常像。都是页面 组件 全局配置的套路模板语法也相近甚至很多小程序开发者刚上手另一边时会觉得“这我熟”。但真写起来你会发现 API 前缀完全不同微信是 wx.xxx钉钉是 dd.xxx。比如网络请求微信用 wx.request钉钉用 dd.request轻提示一个叫 wx.showToast另一个叫 dd.showToast。看着对应关系简单但坑在于不是每个接口都能一一对应。我迁移过一个内部工具微信里用了 wx.getUserProfile 拿用户资料到了钉钉这套完全不存在钉钉里想用 dd.biz.contact.choose 直接弹出组织通讯录选人微信里也没有这种能力只能自己做一个搜索员工的页面。还有蓝牙、NFC、Wi-Fi 这类硬件能力微信封装得更多更细钉钉的开放重点则在办公场景上。你要是把所有 API 抽象成“微信有的钉钉不一定有钉钉有的微信一定没有”心态会平和很多。实际操作上我的习惯是建一个 platform.js 适配层把所有平台相关的调用收口到同一个文件里。头文件判断当前环境可以用“是否定义了 dd 全局对象”来区分然后在里面分别实现登录、请求、提示、选择联系人、获取定位等统一方法。业务页面只调用适配层暴露的方法不要在业务代码里到处写 if (dd) / else。const env typeof dd ! undefined ? dd : wx; const api env dd ? dd : wx; function showToast(title) { api.showToast({ title }); } module.exports { env, showToast, };2.2 登录与鉴权从用户中心到组织中心微信登录的标准链路是前端 wx.login 拿 code后端拿 code 到自己服务器换取 openid然后签发自定义登录态比如 token。后续请求都带这个 token。前端还需要引导用户授权手机号保存用户资料到自己的用户表整个过程跟传统的“App 注册登录”没有本质区别。钉钉的免登链路更短前端 dd.runtime.permission.requestAuthCode 拿 authCode 再交给后端后端拿 authCode 调钉钉服务端接口换取 userId。拿到 userId 后可以直接查询用户在组织里的部门、职位、工号等信息。免登的意思就是员工不需要额外输入企业账号和密码直接用钉钉的身份进入应用。// 微信侧登录 function loginWx() { return new Promise((resolve) { wx.login({ success: (res) resolve(res.code), }); }); } // 钉钉侧免登 function loginDd() { return new Promise((resolve) { dd.runtime.permission.requestAuthCode({ corpId: yourCorpId, onSuccess: (info) resolve(info.authCode), }); }); } function login() { return env dd ? loginDd() : loginWx(); }这里特别提醒一下钉钉免登能不能调通很大程度上取决于应用后台的权限配置。你需要在钉钉开放平台后台配置应用的服务器出口 IP、授权范围、以及“通讯录权限”等接口权限。我踩过最典型的一个坑是后端调用户信息接口一直返回没有权限前端免登却一切正常。查了半天发现是应用的通讯录权限没有申请同事账号根本不在授权范围内。另一个坑是 authCode 是一次性的而且有效期很短后端拿到必须马上使用不能存到库里下次再用。2.3 企业级能力审批、考勤、消息推送的差距钉钉小程序一个突出的优势是它和钉钉办公套件深度打通。你可以直接创建审批实例把费用报销、请假、用章申请等流程接到钉钉原生审批流里可以读取考勤打卡结果做迟到早退统计看板可以创建日程和会议提醒还可以通过工作通知接口向组织内特定用户或部门发送应用程序的通知卡片。这些能力微信基本都没有对应物。微信的订阅消息虽然也能触达用户但每次都要用户主动订阅而且授权一次只能推送一次根本不适合做成“审批待办提醒”这种高频场景。微信的位置、蓝牙、支付、卡券、快递地址能力很丰富适合做线下到店、电商交易、营销活动这类C端业务。所以你在画技术方案时不要试图在两个平台上追求功能完全对等。先想清楚核心业务流程长在哪个生态里。比如一个销售拜访应用核心是记录客户、提交拜访计划、让主管审批那钉钉天然合适审批和待办通知都是现成的。如果核心是用户在线下单、支付、查物流那微信是必须做的钉钉那一套办公能力帮不上忙。2.4 调试与工具链模拟器、真机、权限角色微信开发者工具和钉钉开发者工具整体都很成熟都支持代码编辑、编译预览、真机调试、日志查看。但两边有一个很不一样的调试心态微信里你要模拟的是各种不同类型、不同来源的陌生用户钉钉里你要重点验证的是不同组织角色的权限表现。比如同样一个报修应用普通员工登录看到的是“我要报修”部门主管看到的是“我下属的报修单”维修工看到的是“待接单列表”。微信开发者工具里你要手动切用户身份模拟普通用户、付费用户、企业用户钉钉工具里配合后台的角色配置真机扫码预览时切换不同账号能看到完全不同的页面和数据范围。两个工具的编译模式都支持自定义启动页面和参数这在实际开发里非常有用建议把不同角色、不同参数的入口都做成编译模式预设省得每次调试都手动扫码进入深级页面。此外真机调试时要注意钉钉很多API依赖特定客户端版本开发文档里的“最低支持版本”不是随便写的低版本钉钉上调用会直接报错或者静默失败这两个平台都是如此但钉钉由于需要跟组织管理员客户端版本绑定问题会更棘手。3. 界面规范与交互设计C端体验与B端效率之争3.1 视觉风格与信息密度微信小程序的设计规范是奔着转化率去的。页面要克制按钮要清晰每一步操作都不能让用户犹豫整体视觉风格更强调轻量、留白、品牌感。你会发现微信小程序里大量使用卡片式布局、大标题、大按钮因为消费场景里用户是“逛”的心态视觉上的引导很重要。钉钉小程序的设计倾向是信息密度高、任务导向。工作台本身就是一堆工具入口应用内部常见的形态是列表、筛选器、状态标签、批量操作按钮。一个审批列表页恨不得一屏展示更多的单据和状态因为员工每天打开这个页面的目的是处理任务不是在欣赏设计。这就引出一个很实际的问题同一个设计稿很难两端通用。我有一次把微信端的视觉规范硬套到钉钉端结果页面在钉钉里显得太“空”一个屏幕只能看到两条数据操作效率很低反过来把钉钉的列表密度套到微信端又被吐槽像后台管理系统。两边的设计规范都是无数产品沉淀出来的最优解建议遵守不要强行统一。3.2 导航、安全区与自定义头部导航和顶部安全区是容易被忽略、但是最容易翻车的点。微信小程序的默认导航栏高度、胶囊按钮的位置很多开发者已经形成肌肉记忆。钉钉客户端的结构不一样顶部可能有工作台返回入口自定义导航栏时如果直接照搬微信的顶部高度计算大概率会出现标题顶到状态栏、胶囊遮挡操作按钮的情况。我的建议是能用默认导航栏就尽量用默认导航栏省掉大量适配工作。如果业务确实需要自定义头部不要写死状态栏高度和导航栏高度要分别读取两边的系统信息接口动态计算。钉钉侧还需要考虑不同版本客户端的差异有条件的团队做一到两款主流机型的真机适配检查。另外要注意返回逻辑。微信小程序页面栈返回时遵循标准的栈规则用户从分享卡片进入时可能没有上一页需要设计返回首页的兜底。钉钉小程序嵌在组织客户端内页面返回还涉及从工作台进入的场景这时候“返回”到底返回到工作台还是上一个页面产品上要提前定清楚技术上最好在 onShow 里做一次路由状态检查。3.3 分享、DING与消息触达微信的能力重点是分享和传播。小程序可以带参数分享给单个好友或群结合海报、扫码非常利于社交裂变。在微信生态里分享不是一个附加功能而是业务增长的主要杠杆很多运营玩法都围绕分享展开。钉钉的触达体系是消息驱动。工作通知、群机器人、DING消息、日程提醒这些都服务于“把任务准确推到该处理的人面前”。比如一个请假审批申请人提交后系统通过工作通知推送给审批人审批人点卡片直接进入小程序详情页完成审批再自动通知申请人结果。这个闭环在微信里很难做得这么顺畅因为订阅消息需要用户反复授权而且授权一次只能发一次不适合做有状态的流程推送。如果你要在钉钉里做群分享可以带上业务参数同事在群里点开卡片直接定位到具体单据这是很好的体验。但我建议分享按钮的位置和触发条件要想清楚内部系统里的分享是“有目的的传递”不像微信那样是“随手的转发”不要做一键分享到所有群的泛传播。4. 场景适配与双端同构方案4.1 内部工具选钉钉外部获客选微信大多数团队会问我到底该做哪一端我的判断标准很简单核心用户是谁。用户是员工、供应商、渠道伙伴需要通过组织身份协作选钉钉。用户是消费者、潜在客户、公域流量选微信。举两个例子方便理解。一个场景是设备报修。如果只做微信小程序你得自己维护用户注册登录还要设计两种角色报修人和维修工并且要让工人能看到分配给自己的工单门店管理员能看到所有工单这些权限体系全部从零搭建。如果做钉钉小程序员工本身就是组织成员组织架构自带部门层级人员离职入职自动同步审批流还能挂到钉钉原生审批后台开发量能省一大截。另一个场景是连锁门店的点单小程序。用户是消费者他们不会为了喝杯奶茶去下载钉钉所以必须做微信小程序。扫码、小程序码、社交分享、支付闭环微信把整个消费者路径都铺好了。这时候做钉钉端意义就不大。4.2 双端同构的技术落地策略如果业务确实要求微信和钉钉两端都要上我不建议你并行开发两套代码。更合理的策略是核心业务逻辑复用平台差异隔离。具体做法可以分成三层业务层页面数据、交互状态、表单逻辑尽量写成一整套与平台无关的模块只在页面层做差异布局。适配层所有平台能力调用收口到同一个文件导出统一的 login、request、toast、chooseContact、navigateTo 等方法内部根据环境分发到 wx 或 dd。服务端登录态做统一映射不管你从哪端进来最终服务端都产生一个统一的 user 对象内部再区分 userType 是 external 还是 internal。这里要特别强调服务端的用户模型不能偷懒。同一个真实用户可能在微信端是消费者在钉钉端是员工两边 userId 不一样。如果你不做映射后续做数据打通时会产生大量脏数据。建议在 user 表上增加 platform 和 platformUserId 字段同时留一个 bizUserId 作为业务唯一标识。包体大小也需要注意。两端的静态资源限制都比较严格项目里大量使用本地大图是走不通的要养成图片走 CDN、组件按需加载、路由懒加载的习惯。如果项目一开始就是按双端同构来设计的尽量把公共组件放到独立目录避免两端各自复制代码否则后续修一个 bug 要改两遍。5. 发布审核、灰度与版本管理5.1 静态资源、分包与启动性能微信小程序对主包有严格的体积限制普通小程序的资源超了就必须用分包策略把低频页面、独立业务模块拆到分包里否则上传代码那一步就会被拦下来。钉钉小程序同样有包体限制做企业内部应用时不光是审查严不严的问题是钉钉客户端在弱网环境下加载大包体应用的体验会非常差员工在工厂里打开应用一直转圈这个应用基本就废了。包体优化的几个标准动作是大图片压缩成 WebP 并从代码包里移除、公共库抽成独立 vendor、页面按需注册组件、不打包后端模板文件。还有一个容易忽略的坑是不要把所有页面都写在 app.json 里然后全量加载钉钉和微信都支持按需注入配置不合理会导致启动页面白屏时间变长。5.2 审核规则与上架流程差异微信小程序的发布要经过微信公众平台的审核类目资质、隐私政策、内容安全都要过一遍审核不过的常见原因包括缺少用户隐私保护指引、类目与内容不符、诱导分享等。现在微信对隐私合规的检查很严格代码里有任何读取用户信息却没有在后台声明对应接口的行为都可能在提审时被打回。钉钉小程序的上架分两种场景。一种是发布到钉钉应用市场这种审核也比较严格需要提交应用截图、功能说明、隐私合规等材料另一种是作为企业内部应用发布到自己的工作台审批权在企业管理员手上更多是走内部合规流程。内部应用通常不需要面对外部应用市场那么复杂的审核但安全合规的要求依然存在比如服务器的数据存储位置、日志留存、账号权限管理企业在自测时要想清楚。5.3 灰度发布与回滚策略微信小程序有版本管理后台可以设置体验版通过体验版二维码给团队成员测试再提交正式版发布。发布后如果要紧急回滚可以在后台把线上版本切换到上一个已发布版本生效速度很快。钉钉的企业内部应用发布相对灵活但同样建议做灰度。比较稳妥的做法是先在公司内部一个小部门范围内试运行确认无问题后再全员开放。不要一上来就把所有页面、所有操作开放给全员一旦某个权限配置有误全体员工都会看到不该看的数据这个风险在内部系统里比外部产品更严重。版本缓存也是一个很常见的坑。小程序发布新版本后用户不一定立即拿到微信侧会在用户冷启动时检查更新钉钉侧对已打开过的应用也有缓存。如果服务端接口做了不兼容升级老版本前端调用新接口可能会报错建议在小程序启动时主动调用更新管理接口做静默更新必要时通过线上配置做强制版本升级。6. 踩坑实录常见问题与排查对照6.1 域名白名单和HTTPS校验两个平台都要求前端请求的接口域名配置到后台白名单并且强制 HTTPS不支持 IP 直连和自定义端口。开发模式下可以不校验域名但一上线就全盘报错。排查建议按这个顺序来先看后台白名单里有没有配这个域名再看域名证书链是否完整最后用浏览器直接访问接口看是否有证书问题或重定向。常见的情况是后台配的域名是 abc.example.com代码里请求的却是 www.abc.example.com差一个子域都算不合法。另一个坑是接口里带了非标准端口比如 https://api.example.com:8443这两个平台基本都不支持运维在配置网关时要把端口隐藏掉。6.2 用户信息获取与授权策略微信侧获取用户头像昵称的规则改过好几轮现在很多场景不建议强制用户授权而是用默认头像昵称加“点击修改”的方式等用户主动触发时才拉起授权弹窗。如果一进页面就弹授权被拒绝后后续再弹会非常困难。钉钉侧获取用户信息主要靠后端接口不需要前端弹窗授权。但应用必须具备对应的通讯录权限范围否则后端接口返回无权限。前面已经说过这里再强调一遍如果用户信息接口报了“Insufficient Permissions”或类似错误先去开放平台后台确认权限范围再看服务器出口 IP 是否配置。切勿以为是前端代码问题不然会浪费很多时间。6.3 自定义导航和页面栈问题自定义导航栏是问题重灾区。两端的胶囊按钮、系统返回按钮位置都不同直接沿用微信那套顶部布局算法到钉钉里基本都会出现错位。如果非要做自定义头部建议动态获取顶部安全区域和胶囊位置再计算导航栏高度不要使用固定 64pt 或者 88rpx 这种魔法数字。页面栈问题也同样容易被忽略。微信小程序从外部 share 卡片进入时没有上一页按返回键会直接退出小程序这时需要自己判断页面栈深度并兜底跳转到首页。钉钉里从工作台进入应用和从 IM 卡片进入应用页面栈初始状态不一样如果代码里默认页面栈里一定有上一层会出现返回地址异常。6.4 登录态过期与多身份切换钉钉小程序里同一个设备可能在不同企业组织之间切换或者同一个员工从 A 企业调到 B 企业。切换组织后之前应用里缓存的登录态理论上已经失效但很多代码不会自动感知用户还停在旧的业务页面上操作就会出现接口报错或者看到别的组织数据。我建议你在小程序 onShow 的时候主动校验一次身份状态前端发现用户身份发生变化时清理本地缓存并触发重新登录。后端接口也要在关键操作上做组织ID校验不能只信任前端传来的参数。微信侧没有组织切换问题但用户可能在小程序间跳转登录态过期一样要处理请求返回 401 时统一拦截并跳转到登录页。6.5 模拟器正常真机异常这是所有小程序开发都会遇到的问题。模拟器里跑得好好的真机一打开就白屏、接口报错、样式错乱。常见原因无非是域名校验、客户端版本兼容、以及真机网络环境不同。此外开发者工具默认关闭了很多安全校验真机上这些校验全部生效所以“模拟器正常”根本不代表代码没毛病。一个比较稳妥的做法是准备一台专门的测试手机每次提测前至少跑一遍核心链路登录、进入首页、发起一个完整业务流程、退出登录。同时要留意两端客户端的版本差异钉钉很多API要求客户端不低于某个版本员工手机上的钉钉版本过旧会导致功能不可用。这种情况在微信侧也存在但钉钉的企业环境里员工客户端版本分布更难控制必要时可以在应用里做一个版本检测和升级引导。某个项目组曾经在两套小程序里同步复用一个业务组件改 bug 时只改了微信侧钉钉侧漏了一处结果上线后钉钉用户直接无法提交表单。从那以后我们定了规矩任何公共代码的修改两端的回归测试必须同步跑谁也不能只测一边就宣布提测完成。双端开发最难受的一点就是你以为你在写一份代码实际你在维护两个生态习惯完全不同的应用。这个感受不亲自做一遍很难体会。如果想省心选型阶段就要坚决一点内部协同场景锁定钉钉消费者场景锁定微信。两套都做时也务必把平台差异收口在适配层让业务代码尽量保持干净。最后分享一个小技巧。我习惯在项目里用一个统一的环境判断文件里面不只区分微信和钉钉还会区分开发者工具、真机预览、正式版环境。平时进页面时把环境信息打印在调试日志里排查问题的速度快很多。这些细节看着不起眼在团队协作时能帮你减少大量“我这正常啊”的扯皮时间。两种小程序各有各的道想清楚到底要干什么比纠结选哪家更重要。