1. 项目概述同样叫“小程序”骨子里是两套东西先说结论钉钉小程序和微信小程序虽然都叫小程序但它们的底层架构、开发语言、API设计、审核机制、运营玩法几乎没有一处是相同的。我之前接过一个“从微信小程序迁移到钉钉小程序”的单子原本以为复制粘贴改改API就行结果真做起来才发现这跟从零开发一个App的差距差不了多少。你如果只是把它当成“微信小程序的换皮版”大概率会在登录鉴权、文件下载、容器能力这些地方栽跟头。这个题目适合三类人看一是正在评估“到底该做微信小程序还是钉钉小程序”的产品和技术负责人二是已经写好了一套微信小程序、想低成本复用到钉钉生态的开发者三是对小程序开发感兴趣、想搞清楚这些超级App的小程序容器到底差异在哪儿的初学者。读完这篇文章你能形成一张清晰的决策地图什么时候选钉钉、什么时候选微信、两边的技术栈要准备哪些改造量、踩过哪些坑之后怎么绕开。需要先说明的一点是这里讨论的“钉钉小程序”和“微信小程序”都是各自平台官方推出的原生小程序体系不是市面上那些多端编译框架这类框架后面也会聊到。原生体系虽然学习成本稍高但是调用平台原生能力最直接、性能最可控的方式。2. 本质差异服务对象决定了技术形态2.1 一个面向组织一个面向公域要从根上理解两者的区别先要回答一个问题这个小程序跑在什么样的流量环境里微信小程序面对的是一个接近全覆盖的C端用户池。用户的画像千差万别使用场景可能是排队点杯奶茶、看一篇资讯文章、给手机充个话费。这种环境决定了微信小程序的核心能力是“获取新用户、拉活、转化”所有API设计都是围绕支付、订阅消息、分享裂变、搜索召回这条链路展开的。钉钉小程序则完全不同。它跑在组织协同的场景里访问者是企业内部的员工、管理者以及与企业有业务往来的外部协作方。这个小程序承载的业务往往是考勤打卡、审批流转、设备巡检、销售上报、内部知识库这类典型的办公场景。所以它的API体系里全是通讯录查询、免登鉴权、消息通知、日程、审批、会议这类跟组织身份强绑定的能力。这两种定位差异直接影响技术形态。微信小程序的用户体系是openid与unionid同一个用户在不同公众号、小程序、App之间需要依靠unionid来统一身份。钉钉小程序则是corpId加userId的结构员工身份挂在某个企业组织下离开这个组织同一个手机号对应的userId可能完全不同。也就是说钉钉小程序在设计之初就必须考虑“多租户”的组织隔离问题。2.2 小程序容器和渲染机制上的血缘关系很多人不知道钉钉小程序和支付宝小程序在技术路线上有很深的血缘关系。钉钉早期的小程序容器就引入了支付宝小程序的一整套架构方案所以在钉钉开发者工具里你会看到它支持.axml和.acss这类文件后缀跟微信小程序经典的.wxml与.wxss有明显差异。两者都采用了“双线程模型”——逻辑层跑JavaScript渲染层由WebView或原生组件承载。但更具体的实现细节上微信小程序的渲染层与逻辑层通信靠的是setData这条通道频繁调用会引发性能瓶颈所以微信官方一直强调要控制setData的数据量。钉钉小程序同样有这个限制但它在组件化和API命名上更靠近支付宝的风格。开发者从微信转过来之后最直观的感受就是文档风格、IDE界面、调试面板都不一样了。如果你用过支付宝小程序再转钉钉那种适应成本反而会小很多。有个很容易踩的坑钉钉小程序虽然支持rpx这种响应式像素单位但它的容器默认会按照钉钉客户端窗口的宽度来计算。如果你在微信里用rpx做了一套UI直接平移到钉钉后发现布局比例不对大概率就是这个单位在不同容器里的计算基准不同导致的。我的经验是钉钉小程序里优先使用px加弹性布局或者用rem配合媒体查询尽量别依赖rpx的自动换算。2.3 技术选型背后的产品逻辑微信小程序的审核和上线逻辑也更偏向“App Store模式”——开发者通过微信公众平台提交代码微信的审核团队进行规范性检查通过后发布到线上。这个审核体系保证了公域内容的基本质量但也让很多企业内部工具发布变得很低效。而钉钉小程序走的是“企业应用市场模式”应用在平台发布后需要企业管理员在管理后台安装、配置权限成员才能在工作台里使用。这相当于把“安装”这个动作交给了企业管理员而不是让终端用户自己去搜索添加。搞清楚这个逻辑之后你就不会问出“为什么我在钉钉开发者后台发布了小程序却搜不到”这种问题了。关键不是平台审核而是你的企业组织里没有人去管理后台把这个应用上架并授权到工作台。这个机制上的差别也直接决定了两个平台上的小程序在代码体积、包体积限制、插件使用策略上的不同取向。3. 开发环境与项目结构对比3.1 IDE、工程初始化与调试工具开发微信小程序时你需要在微信开发者工具里创建一个项目填写AppID然后工具会生成一个标准的项目骨架。整个开发调试过程中工具自带模拟器、真机预览、上传代码、查看console日志的能力而且微信开发者工具对npm构建、TypeScript模板、eslint配置做了不少内置支持。钉钉开发者工具则长得很像又一个支付宝小程序IDE的重构版。它同样支持从模板创建项目、模拟器调试、真机预览但登录方式要求你先用钉钉扫码然后选择要关联的企业组织。在实际使用中我发现钉钉工具的调试面板在真机预览的启动速度和断点调试体验上跟微信开发者工具还有一些差距。尤其是服务端API的联调钉钉环境里你需要先在后台配置服务器出口IP和白名单这个“顺手”的配置环节经常是团队协作时最先出问题的地方。如果你所在团队同时维护两个平台的工程强烈建议把两套IDE都装好不要图省事只依赖命令行工具。因为两个平台对项目配置文件的识别逻辑不一样比如钉钉小程序需要mini.project.json作为配置文件而微信小程序读取的是project.config.json两者不能混用。3.2 目录结构与页面生命周期差异真的很不一样看一下两种小程序的典型目录结构差异是肉眼可见的。微信小程序的标准骨架长这样├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── index/ │ │ ├── index.js │ │ ├── index.json │ │ ├── index.wxml │ │ └── index.wxss ├── components/ ├── utils/ └── project.config.json钉钉小程序的标准骨架则是├── app.js ├── app.json ├── app.acss ├── mini.project.json ├── pages/ │ ├── index/ │ │ ├── index.js │ │ ├── index.json │ │ ├── index.axml │ │ ├── index.acss ├── components/ ├── utils/ └── symbol.config.json从文件结构上就能看出页面的布局描述文件和后缀名全都不通用。微信用的是.wxml钉钉用的是.axml样式文件一个是.wxss一个是.acss。这些后缀改名其实不只是换个名字里面支持的指令语法也存在细微出入。最典型的是循环渲染和条件渲染时使用的表达式方式微信小程序里这样写view wx:for{{list}} wx:keyid{{item.name}}/view view wx:if{{show}}内容/view钉钉小程序里这样写view a:for{{list}} a:keyid{{item.name}}/view view a:if{{show}}内容/view从wx:到a:的变化意味着如果你拿微信的代码直接转到钉钉所有模板上的wx:if、wx:for、wx:key都必须挨个改成a:if、a:for、a:key。这听上去是小活儿但页面一多就很容易遗漏。我的做法是迁移时先全局搜索替换再逐个页面做人工检查这两步缺一不可。生命周期方面两者名称几乎一致onLoad、onShow、onReady、onHide、onUnload都是有的。但需要注意的是钉钉小程序里页面滑出屏幕时onHide的触发时机在不同版本客户端上有差异我在一些老版本的钉钉客户端上遇到过页面被盖住但onHide不触发的状况。如果你依赖onHide去暂停音视频或保存草稿建议顺便加一个onPageResume和onPageHide来双保险。3.3 API风格wx.还是dd.这是个问题代码写起来满屏都是区别。微信小程序的API都是通过wx.xxx()调用钉钉小程序则是dd.xxx()。命名习惯也差异明显微信典型的调用方式wx.login({ success: (res) { console.log(res.code) } }) wx.request({ url: https://api.example.com/xxx, method: POST, data: {}, header: { Content-Type: application/json } })钉钉则是dd.getAuthCode({ success: (res) { console.log(res.authCode) } }) dd.httpRequest({ url: https://api.example.com/xxx, method: POST, data: {}, headers: { Content-Type: application/json } })一眼就能看出来API的设计逻辑相似但名称完全不同。更重要的是很多API门槛不一样。微信的wx.getUserProfile经历了多次权限收紧调整现在已经没法像早期那样直接弹窗拿头像昵称了。钉钉的dd.getUserInfo则跟组织通讯录权限强绑定你在钉钉后台给应用授了哪几个权限点前端才能拿到哪部分数据。这里有一个非常关键的坑钉钉小程序里dd.getAuthCode拿到的authCode有效期非常短我记得早期文档建议是五分钟内必须换取用户身份信息而且这个code只能换取一次。如果你在代码里设计成“先存下来、等到某个操作步骤再换取”中途刷新页面或者长时间停留在表单页code就极有可能失效。正确姿势是在小程序启动时进入某个页面后立即调用dd.getAuthCode并在同一轮异步流程里请求后端完成身份换取。4. 核心细节登录、文件、组件与容器能力的差异4.1 登录鉴权链路完全不是一回事微信小程序的登录链路由wx.login获取临时code然后传给后端调用code2Session接口换取openid和session_key。这套链路的基础是每个用户都有一个相对稳定的微信身份标识。钉钉的登录链路则复杂一层因为要带上组织信息。钉钉小程序真实业务里的登录链路一般是前端调用dd.getAuthCode获取临时授权码后端收到授权码后调用钉钉开放平台的接口传入authCode、应用的AppKey和AppSecret换取用户的userId和所属的corpId后端拿corpId和userId唯一确认用户生成自己的会话令牌返回给前端。这里有个特别容易出错的细节dd.getAuthCode的签名参数里经常要传corpId。如果你在开发阶段用的是企业内部测试应用粒度还比较宽松一旦你开发的是“定制应用”或“第三方应用”这个corpId的获取方式会和内部应用有很大区别稍不留神就会拿到一个空值。安全方面微信和钉钉现在都要求开发者在后端完成令牌校验前端尽量不要保存敏感身份信息。但是因为钉钉本身带着企业身份你的后端还必须考虑“离职员工”的权限回收问题。用户会被管理员移出组织、停用账号这种操作在微信生态里根本不存在但在钉钉生态里非常普遍。所以你在钉钉小程序后端设计鉴权中间件时必须增加一道组织成员有效性校验不能只信任自己签发的token。4.2 文件与企业网盘能力企业内部场景的特殊点微信小程序里的文件下载、保存、分享链路相对直接用wx.downloadFile下载临时文件再通过wx.saveFile或wx.openDocument查看。这一切围绕的是用户自己的手机存储和微信内部的临时文件机制。钉钉小程序里情况完全不同因为文件通常和钉盘、审批附件、会话消息里的资源ID绑定。你要下载一个审批附件需要先从钉钉API拿到文件的下载链接但这个链接往往带有时效性而且受后端权限控制。某团队在开发模拟项目X时就遇到过一个非常典型的坑从钉钉消息里拿到的消息体里面是一个fileId或spaceId的组合并不是一个可直接下载的HTTP链接。你还需要再调用一次钉钉的“获取文件下载信息”接口拿到临时链接然后才能在小程序里通过dd.downloadFile下载到本地。这一步很多人会漏掉结果就是前端一直报“无效链接”或者403排查半天。微信里“转发给朋友”也是默认支持的能力钉钉里也一样但钉钉的转发维度更多可以转到单聊、群聊、或者某个钉盘空间。如果你开发的应用里涉及附件分享需要仔细查看对应API的参数要求别想当然按微信文档里的转发参数直接照搬。4.3 组件生态官方组件和第三方组件的差距微信小程序的第三方组件生态非常丰富像vant-weapp、TDesign、weui这类UI库你随便挑社区模板多到看不过来。钉钉小程序在这方面就小众很多了虽然也有官方提供的“钉钉小程序组件库”但无论从组件数量、维护频率还是社区答案数量来看都比微信生态差了不止一个数量级。这意味着什么意味着你写钉钉小程序界面时很多基础组件可能要自己封装。比如一个企业内部的日期区间选择器、一个部门树选择器、一个嵌套表格在微信里也许找个现成组件改改就行在钉钉里大概率要从零写。我曾经在模拟项目X里为了做一个“多级审批人选择树”折腾了将近两天因为现成的组件库没有适配钉钉的小程序语法。另一个很实际的差异在于web-view的配置策略。微信小程序里你可以在业务域名后台配置合法的网页域名小王页面里就能通过web-view加载外部H5。钉钉小程序同样有web-view但它的域名校验机制和企业应用的“可信域名”配置绑在一起你在开发环境还能通过“忽略域名校验”来调试到了生产环境域名不在白名单里就根本打不开。所以上线前必须确认这些域名都提前配好否则真机预览全是一片空白。5. 发布上架与企业权限管理5.1 审核机制与灰度发布策略幽灵般的对比点在这里。微信小程序的发布是一个硬性审核流程。从提交代码、填写版本描述、提交审核到通过通常需要一两天有时候遇到复杂类目还会被驳回要求补充资质材料。如果你是做企业内部工具也用微信小程序版本就得忍受这种审核周期。钉钉小程序的发布模式则更像“企业内部应用市场”。开发者在钉钉开放平台创建应用、开发完版本后提交的并不是类似于微信的集中式人工审核而是应用信息与安全检测。发布动作本身是在钉钉开发者后台完成的但应用能不能出现在某个企业的工作台里完全取决于这个企业的管理员在管理后台是否安装了该应用。这两者的差别对交付节奏影响很大。微信小程序上线追求的是“全网可见”所以要统一接受规范约束钉钉小程序追求的是“企业内快速部署”所以审核逻辑需要给管理员放权。学会了这一点你在做To B交付时就能灵活运用如果客户要求某一个部门先试用钉钉的应用权限可以精确到部门甚至人微信小程序做不到这种细粒度的企业内部分发控制。5.2 权限点配置一不小心就少传参数钉钉开发后台的“权限管理”页面会列出一大堆权限点通讯录读取、用户信息读取、考勤数据、审批实例、日程管理、文件上传等等。这些权限点并非开了就完事它们在创建应用之后还需要与AppKey、AppSecret一起配合使用。实际开发中我见过好几次这样的情况后端调用API时报错“no permission”排查到最后发现不是代码问题而是开发者在钉钉后台新建应用时没有勾选对应的权限点。这是一个很隐蔽的坑因为在微信生态里你用到的接口权限基本是“默认开启”的顶多是需要用户主动授权一些敏感能力。钉钉则完全反过来默认关闭手动开启而且权限点更新之后通常需要几分钟甚至更久才会全局生效。所以养成的习惯是在钉钉项目里新接入任何一个开放接口前先去后台把对应权限点全部打勾保存然后再写代码。等代码写完才来查权限调试效率会非常低。5.3 多端兼容的小程序框架是否值得引入如果你既想覆盖微信又想覆盖钉钉自然要想“有没有一套代码两边跑的办法”。市面上确实有一些多端开发框架比如跨端编译方案、开放平台提供的多端开发工具等思路都是“一次编写、多端编译”。这类框架很诱人但我必须给你泼一点冷水它们对业务常见的渲染、请求、路由也许兼容得不错一旦你用到平台特有的能力比如钉钉的审批API、或者微信的支付能力框架强行包装的接口往往要么支持不完全要么参数转换时出问题。跨平台框架适合业务逻辑简单、UI不复杂的工具类应用如果你的钉钉小程序核心业务就围绕审批、考勤这些平台原生流程展开那我还是建议直接写原生钉钉小程序不要用框架硬套。身边有一个团队曾经用多端框架写钉钉消息推送结果发现框架封装的推送API需要依赖“钉钉工作通知”接口而这个接口的权限校验和普通API不一样在框架层很难灵活透传corpId最后还得写原生代码来收尾。两套成本叠加后比一开始分开维护还要吃力。6. 常见问题排查与避坑经验6.1 真机预览时白屏、接口报错我在钉钉小程序开发中遇到的第一个高频问题就是真机预览打开白屏。排查步骤是这样的第一确认调试器里是否打印了app.js的onLaunch报错。钉钉对JS报错的处理比微信严格一个未被捕获的异常可能导致整个页面渲染失败而微信端可能只是console里多一条错误。第二检查钉钉开发者工具里的“域名校验”开关。开发阶段可以临时关掉但过了开发阶段后发现线上也白屏多半就是请求域名不在白名单里。第三看小程序的启动参数是否合法corpId是否传对了。有时候你在工具里调试是正常的一旦切换到真机预览默认带入的企业上下文发生变化可能导致dd.getAuthCode返回空码。关于请求报错最常见的是401或403。401一般是后端换authCode时候用了过期的AppSecret或者code已经被使用过。403多为后端IP不在服务器出口白名单里这种情况你需要在钉钉开放平台后台配置后端服务器的出口IP否则请求根本到达不了钉钉的服务端接口。6.2 从微信小程序迁移到钉钉小程序的关键改造清单可能很多团队的第一反应是拿微信小程序代码直接迁。为了减少踩坑我把迁移过程中最容易被遗漏的改动项整理成一张速查表改造项微信小程序钉钉小程序模板指令wx:if / wx:for / wx:keya:if / a:for / a:key样式尾缀.wxss.acss布局文件后缀.wxml.axml全局API前缀wxdd登录接口wx.logindd.getAuthCodeHTTP请求wx.requestdd.httpRequest本地存储wx.setStorageSyncdd.setStorageSync数据监听observer / setDatasetData无observer或需自行实现用户信息wx.getUserProfiledd.getUserInfo依赖通讯录权限文件下载wx.downloadFiledd.downloadFile 获取下载信息接口分享wx.shareAppMessagedd.shareToChat配置文件名project.config.jsonmini.project.json这张表只是最基础的清单真做起来还要逐函数排查。比如微信的wx.showToast支持icon参数里的loading、success、none钉钉的dd.showToast类型名称可能变成success或fail你传一个微信风格的枚举值进去钉钉可能直接忽略图标设置。多个团队实测下来一个中等复杂度的页面大约二三十个交互逻辑、十几个接口调用从微信迁移到钉钉纯搬代码加调试如果是熟练开发者大概需要三到五天。如果页面涉及审批、考勤、外部联系人这些特有开放API工期还会翻倍。6.3 权限、白名单和组织身份校验的坑最后一个大坑是组织身份。钉钉小程序天然自带To B属性但你写的应用可能会同时被很多不同企业安装。也就是说同一个后端服务要能清晰地识别出“当前请求来自哪个企业、哪个员工”。如果你只是用userId做数据隔离不去校验corpId很有可能会发生传说中的“越权问题”——同一个userId在不同企业里指向的是不同的人串号之后数据就乱了。我的处理方式是统一在后端维护一张“企业成员映射表”以corpId userId作为联合唯一键每次请求都在中间件里校验这个联合键是否有效。同时定期调用钉钉通讯录接口做增量同步保证离职员工及时从表里移除。这个设计在微信小程序里几乎没有对应物但在钉钉里属于必须要处理的问题。7. 怎么选写给产品经理和技术负责人的决策建议如果你的目标用户是普通消费者、你需要的用户规模是百万级、你需要裂变分享和微信支付这类能力选微信小程序没有任何悬念。如果是一个企业内部的管理工具使用人群是本公司员工或者客户企业的员工核心业务流程涉及审批、考勤、日程、组织通讯录那么钉钉小程序的优势极其明显——身份免登、组织数据、审批集成都是平台原生能力你不需要自己做一套账号体系和权限树。假如你的产品走的是“企业服务SaaS”路线想卖给很多家企业那么你大概率需要做成钉钉生态里的第三方应用。这时你就要重点研究两个模型企业内部应用和第三方应用。两者的接口权限、上架流程差别很大内部应用开发起来更简单但只能在一个企业范围内使用第三方应用要走应用市场审核同时要适配多企业定制化配置复杂度要高不少。从团队技术栈规划角度讲如果未来一年内只有钉钉一种To B侧需求就专注原生开发。如果两种都要覆盖那就要评估业务里平台API的使用深度。纯展示类、轻交互、不做复杂数据上报的东西引入多端框架是正确的。而业务一碰审批、支付、模板消息这类深水区还是老老实实分开维护两套代码。我个人在实际操作中的体会是不要在项目早期把“一套代码多端覆盖”想得过于美好。微信和钉钉的表面语法差异其实通过一些组件封装就能抹平真正抹不平的是平台背后的组织关系、身份体系和审核流程。这种差异从技术栈一直延伸到产品设计是没法靠工具链彻底弥合的。你在选型那天多花一上午想清楚核心用户在哪比后期省下的三个月的迁移成本划算得多。 
长河君 · 2026/10/21 7:54:56 · 阅读 1.2k 钉钉小程序与微信小程序核心差异：架构、登录鉴权与迁移避坑指南
1. 项目概述同样叫“小程序”骨子里是两套东西先说结论钉钉小程序和微信小程序虽然都叫小程序但它们的底层架构、开发语言、API设计、审核机制、运营玩法几乎没有一处是相同的。我之前接过一个“从微信小程序迁移到钉钉小程序”的单子原本以为复制粘贴改改API就行结果真做起来才发现这跟从零开发一个App的差距差不了多少。你如果只是把它当成“微信小程序的换皮版”大概率会在登录鉴权、文件下载、容器能力这些地方栽跟头。这个题目适合三类人看一是正在评估“到底该做微信小程序还是钉钉小程序”的产品和技术负责人二是已经写好了一套微信小程序、想低成本复用到钉钉生态的开发者三是对小程序开发感兴趣、想搞清楚这些超级App的小程序容器到底差异在哪儿的初学者。读完这篇文章你能形成一张清晰的决策地图什么时候选钉钉、什么时候选微信、两边的技术栈要准备哪些改造量、踩过哪些坑之后怎么绕开。需要先说明的一点是这里讨论的“钉钉小程序”和“微信小程序”都是各自平台官方推出的原生小程序体系不是市面上那些多端编译框架这类框架后面也会聊到。原生体系虽然学习成本稍高但是调用平台原生能力最直接、性能最可控的方式。2. 本质差异服务对象决定了技术形态2.1 一个面向组织一个面向公域要从根上理解两者的区别先要回答一个问题这个小程序跑在什么样的流量环境里微信小程序面对的是一个接近全覆盖的C端用户池。用户的画像千差万别使用场景可能是排队点杯奶茶、看一篇资讯文章、给手机充个话费。这种环境决定了微信小程序的核心能力是“获取新用户、拉活、转化”所有API设计都是围绕支付、订阅消息、分享裂变、搜索召回这条链路展开的。钉钉小程序则完全不同。它跑在组织协同的场景里访问者是企业内部的员工、管理者以及与企业有业务往来的外部协作方。这个小程序承载的业务往往是考勤打卡、审批流转、设备巡检、销售上报、内部知识库这类典型的办公场景。所以它的API体系里全是通讯录查询、免登鉴权、消息通知、日程、审批、会议这类跟组织身份强绑定的能力。这两种定位差异直接影响技术形态。微信小程序的用户体系是openid与unionid同一个用户在不同公众号、小程序、App之间需要依靠unionid来统一身份。钉钉小程序则是corpId加userId的结构员工身份挂在某个企业组织下离开这个组织同一个手机号对应的userId可能完全不同。也就是说钉钉小程序在设计之初就必须考虑“多租户”的组织隔离问题。2.2 小程序容器和渲染机制上的血缘关系很多人不知道钉钉小程序和支付宝小程序在技术路线上有很深的血缘关系。钉钉早期的小程序容器就引入了支付宝小程序的一整套架构方案所以在钉钉开发者工具里你会看到它支持.axml和.acss这类文件后缀跟微信小程序经典的.wxml与.wxss有明显差异。两者都采用了“双线程模型”——逻辑层跑JavaScript渲染层由WebView或原生组件承载。但更具体的实现细节上微信小程序的渲染层与逻辑层通信靠的是setData这条通道频繁调用会引发性能瓶颈所以微信官方一直强调要控制setData的数据量。钉钉小程序同样有这个限制但它在组件化和API命名上更靠近支付宝的风格。开发者从微信转过来之后最直观的感受就是文档风格、IDE界面、调试面板都不一样了。如果你用过支付宝小程序再转钉钉那种适应成本反而会小很多。有个很容易踩的坑钉钉小程序虽然支持rpx这种响应式像素单位但它的容器默认会按照钉钉客户端窗口的宽度来计算。如果你在微信里用rpx做了一套UI直接平移到钉钉后发现布局比例不对大概率就是这个单位在不同容器里的计算基准不同导致的。我的经验是钉钉小程序里优先使用px加弹性布局或者用rem配合媒体查询尽量别依赖rpx的自动换算。2.3 技术选型背后的产品逻辑微信小程序的审核和上线逻辑也更偏向“App Store模式”——开发者通过微信公众平台提交代码微信的审核团队进行规范性检查通过后发布到线上。这个审核体系保证了公域内容的基本质量但也让很多企业内部工具发布变得很低效。而钉钉小程序走的是“企业应用市场模式”应用在平台发布后需要企业管理员在管理后台安装、配置权限成员才能在工作台里使用。这相当于把“安装”这个动作交给了企业管理员而不是让终端用户自己去搜索添加。搞清楚这个逻辑之后你就不会问出“为什么我在钉钉开发者后台发布了小程序却搜不到”这种问题了。关键不是平台审核而是你的企业组织里没有人去管理后台把这个应用上架并授权到工作台。这个机制上的差别也直接决定了两个平台上的小程序在代码体积、包体积限制、插件使用策略上的不同取向。3. 开发环境与项目结构对比3.1 IDE、工程初始化与调试工具开发微信小程序时你需要在微信开发者工具里创建一个项目填写AppID然后工具会生成一个标准的项目骨架。整个开发调试过程中工具自带模拟器、真机预览、上传代码、查看console日志的能力而且微信开发者工具对npm构建、TypeScript模板、eslint配置做了不少内置支持。钉钉开发者工具则长得很像又一个支付宝小程序IDE的重构版。它同样支持从模板创建项目、模拟器调试、真机预览但登录方式要求你先用钉钉扫码然后选择要关联的企业组织。在实际使用中我发现钉钉工具的调试面板在真机预览的启动速度和断点调试体验上跟微信开发者工具还有一些差距。尤其是服务端API的联调钉钉环境里你需要先在后台配置服务器出口IP和白名单这个“顺手”的配置环节经常是团队协作时最先出问题的地方。如果你所在团队同时维护两个平台的工程强烈建议把两套IDE都装好不要图省事只依赖命令行工具。因为两个平台对项目配置文件的识别逻辑不一样比如钉钉小程序需要mini.project.json作为配置文件而微信小程序读取的是project.config.json两者不能混用。3.2 目录结构与页面生命周期差异真的很不一样看一下两种小程序的典型目录结构差异是肉眼可见的。微信小程序的标准骨架长这样├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── index/ │ │ ├── index.js │ │ ├── index.json │ │ ├── index.wxml │ │ └── index.wxss ├── components/ ├── utils/ └── project.config.json钉钉小程序的标准骨架则是├── app.js ├── app.json ├── app.acss ├── mini.project.json ├── pages/ │ ├── index/ │ │ ├── index.js │ │ ├── index.json │ │ ├── index.axml │ │ ├── index.acss ├── components/ ├── utils/ └── symbol.config.json从文件结构上就能看出页面的布局描述文件和后缀名全都不通用。微信用的是.wxml钉钉用的是.axml样式文件一个是.wxss一个是.acss。这些后缀改名其实不只是换个名字里面支持的指令语法也存在细微出入。最典型的是循环渲染和条件渲染时使用的表达式方式微信小程序里这样写view wx:for{{list}} wx:keyid{{item.name}}/view view wx:if{{show}}内容/view钉钉小程序里这样写view a:for{{list}} a:keyid{{item.name}}/view view a:if{{show}}内容/view从wx:到a:的变化意味着如果你拿微信的代码直接转到钉钉所有模板上的wx:if、wx:for、wx:key都必须挨个改成a:if、a:for、a:key。这听上去是小活儿但页面一多就很容易遗漏。我的做法是迁移时先全局搜索替换再逐个页面做人工检查这两步缺一不可。生命周期方面两者名称几乎一致onLoad、onShow、onReady、onHide、onUnload都是有的。但需要注意的是钉钉小程序里页面滑出屏幕时onHide的触发时机在不同版本客户端上有差异我在一些老版本的钉钉客户端上遇到过页面被盖住但onHide不触发的状况。如果你依赖onHide去暂停音视频或保存草稿建议顺便加一个onPageResume和onPageHide来双保险。3.3 API风格wx.还是dd.这是个问题代码写起来满屏都是区别。微信小程序的API都是通过wx.xxx()调用钉钉小程序则是dd.xxx()。命名习惯也差异明显微信典型的调用方式wx.login({ success: (res) { console.log(res.code) } }) wx.request({ url: https://api.example.com/xxx, method: POST, data: {}, header: { Content-Type: application/json } })钉钉则是dd.getAuthCode({ success: (res) { console.log(res.authCode) } }) dd.httpRequest({ url: https://api.example.com/xxx, method: POST, data: {}, headers: { Content-Type: application/json } })一眼就能看出来API的设计逻辑相似但名称完全不同。更重要的是很多API门槛不一样。微信的wx.getUserProfile经历了多次权限收紧调整现在已经没法像早期那样直接弹窗拿头像昵称了。钉钉的dd.getUserInfo则跟组织通讯录权限强绑定你在钉钉后台给应用授了哪几个权限点前端才能拿到哪部分数据。这里有一个非常关键的坑钉钉小程序里dd.getAuthCode拿到的authCode有效期非常短我记得早期文档建议是五分钟内必须换取用户身份信息而且这个code只能换取一次。如果你在代码里设计成“先存下来、等到某个操作步骤再换取”中途刷新页面或者长时间停留在表单页code就极有可能失效。正确姿势是在小程序启动时进入某个页面后立即调用dd.getAuthCode并在同一轮异步流程里请求后端完成身份换取。4. 核心细节登录、文件、组件与容器能力的差异4.1 登录鉴权链路完全不是一回事微信小程序的登录链路由wx.login获取临时code然后传给后端调用code2Session接口换取openid和session_key。这套链路的基础是每个用户都有一个相对稳定的微信身份标识。钉钉的登录链路则复杂一层因为要带上组织信息。钉钉小程序真实业务里的登录链路一般是前端调用dd.getAuthCode获取临时授权码后端收到授权码后调用钉钉开放平台的接口传入authCode、应用的AppKey和AppSecret换取用户的userId和所属的corpId后端拿corpId和userId唯一确认用户生成自己的会话令牌返回给前端。这里有个特别容易出错的细节dd.getAuthCode的签名参数里经常要传corpId。如果你在开发阶段用的是企业内部测试应用粒度还比较宽松一旦你开发的是“定制应用”或“第三方应用”这个corpId的获取方式会和内部应用有很大区别稍不留神就会拿到一个空值。安全方面微信和钉钉现在都要求开发者在后端完成令牌校验前端尽量不要保存敏感身份信息。但是因为钉钉本身带着企业身份你的后端还必须考虑“离职员工”的权限回收问题。用户会被管理员移出组织、停用账号这种操作在微信生态里根本不存在但在钉钉生态里非常普遍。所以你在钉钉小程序后端设计鉴权中间件时必须增加一道组织成员有效性校验不能只信任自己签发的token。4.2 文件与企业网盘能力企业内部场景的特殊点微信小程序里的文件下载、保存、分享链路相对直接用wx.downloadFile下载临时文件再通过wx.saveFile或wx.openDocument查看。这一切围绕的是用户自己的手机存储和微信内部的临时文件机制。钉钉小程序里情况完全不同因为文件通常和钉盘、审批附件、会话消息里的资源ID绑定。你要下载一个审批附件需要先从钉钉API拿到文件的下载链接但这个链接往往带有时效性而且受后端权限控制。某团队在开发模拟项目X时就遇到过一个非常典型的坑从钉钉消息里拿到的消息体里面是一个fileId或spaceId的组合并不是一个可直接下载的HTTP链接。你还需要再调用一次钉钉的“获取文件下载信息”接口拿到临时链接然后才能在小程序里通过dd.downloadFile下载到本地。这一步很多人会漏掉结果就是前端一直报“无效链接”或者403排查半天。微信里“转发给朋友”也是默认支持的能力钉钉里也一样但钉钉的转发维度更多可以转到单聊、群聊、或者某个钉盘空间。如果你开发的应用里涉及附件分享需要仔细查看对应API的参数要求别想当然按微信文档里的转发参数直接照搬。4.3 组件生态官方组件和第三方组件的差距微信小程序的第三方组件生态非常丰富像vant-weapp、TDesign、weui这类UI库你随便挑社区模板多到看不过来。钉钉小程序在这方面就小众很多了虽然也有官方提供的“钉钉小程序组件库”但无论从组件数量、维护频率还是社区答案数量来看都比微信生态差了不止一个数量级。这意味着什么意味着你写钉钉小程序界面时很多基础组件可能要自己封装。比如一个企业内部的日期区间选择器、一个部门树选择器、一个嵌套表格在微信里也许找个现成组件改改就行在钉钉里大概率要从零写。我曾经在模拟项目X里为了做一个“多级审批人选择树”折腾了将近两天因为现成的组件库没有适配钉钉的小程序语法。另一个很实际的差异在于web-view的配置策略。微信小程序里你可以在业务域名后台配置合法的网页域名小王页面里就能通过web-view加载外部H5。钉钉小程序同样有web-view但它的域名校验机制和企业应用的“可信域名”配置绑在一起你在开发环境还能通过“忽略域名校验”来调试到了生产环境域名不在白名单里就根本打不开。所以上线前必须确认这些域名都提前配好否则真机预览全是一片空白。5. 发布上架与企业权限管理5.1 审核机制与灰度发布策略幽灵般的对比点在这里。微信小程序的发布是一个硬性审核流程。从提交代码、填写版本描述、提交审核到通过通常需要一两天有时候遇到复杂类目还会被驳回要求补充资质材料。如果你是做企业内部工具也用微信小程序版本就得忍受这种审核周期。钉钉小程序的发布模式则更像“企业内部应用市场”。开发者在钉钉开放平台创建应用、开发完版本后提交的并不是类似于微信的集中式人工审核而是应用信息与安全检测。发布动作本身是在钉钉开发者后台完成的但应用能不能出现在某个企业的工作台里完全取决于这个企业的管理员在管理后台是否安装了该应用。这两者的差别对交付节奏影响很大。微信小程序上线追求的是“全网可见”所以要统一接受规范约束钉钉小程序追求的是“企业内快速部署”所以审核逻辑需要给管理员放权。学会了这一点你在做To B交付时就能灵活运用如果客户要求某一个部门先试用钉钉的应用权限可以精确到部门甚至人微信小程序做不到这种细粒度的企业内部分发控制。5.2 权限点配置一不小心就少传参数钉钉开发后台的“权限管理”页面会列出一大堆权限点通讯录读取、用户信息读取、考勤数据、审批实例、日程管理、文件上传等等。这些权限点并非开了就完事它们在创建应用之后还需要与AppKey、AppSecret一起配合使用。实际开发中我见过好几次这样的情况后端调用API时报错“no permission”排查到最后发现不是代码问题而是开发者在钉钉后台新建应用时没有勾选对应的权限点。这是一个很隐蔽的坑因为在微信生态里你用到的接口权限基本是“默认开启”的顶多是需要用户主动授权一些敏感能力。钉钉则完全反过来默认关闭手动开启而且权限点更新之后通常需要几分钟甚至更久才会全局生效。所以养成的习惯是在钉钉项目里新接入任何一个开放接口前先去后台把对应权限点全部打勾保存然后再写代码。等代码写完才来查权限调试效率会非常低。5.3 多端兼容的小程序框架是否值得引入如果你既想覆盖微信又想覆盖钉钉自然要想“有没有一套代码两边跑的办法”。市面上确实有一些多端开发框架比如跨端编译方案、开放平台提供的多端开发工具等思路都是“一次编写、多端编译”。这类框架很诱人但我必须给你泼一点冷水它们对业务常见的渲染、请求、路由也许兼容得不错一旦你用到平台特有的能力比如钉钉的审批API、或者微信的支付能力框架强行包装的接口往往要么支持不完全要么参数转换时出问题。跨平台框架适合业务逻辑简单、UI不复杂的工具类应用如果你的钉钉小程序核心业务就围绕审批、考勤这些平台原生流程展开那我还是建议直接写原生钉钉小程序不要用框架硬套。身边有一个团队曾经用多端框架写钉钉消息推送结果发现框架封装的推送API需要依赖“钉钉工作通知”接口而这个接口的权限校验和普通API不一样在框架层很难灵活透传corpId最后还得写原生代码来收尾。两套成本叠加后比一开始分开维护还要吃力。6. 常见问题排查与避坑经验6.1 真机预览时白屏、接口报错我在钉钉小程序开发中遇到的第一个高频问题就是真机预览打开白屏。排查步骤是这样的第一确认调试器里是否打印了app.js的onLaunch报错。钉钉对JS报错的处理比微信严格一个未被捕获的异常可能导致整个页面渲染失败而微信端可能只是console里多一条错误。第二检查钉钉开发者工具里的“域名校验”开关。开发阶段可以临时关掉但过了开发阶段后发现线上也白屏多半就是请求域名不在白名单里。第三看小程序的启动参数是否合法corpId是否传对了。有时候你在工具里调试是正常的一旦切换到真机预览默认带入的企业上下文发生变化可能导致dd.getAuthCode返回空码。关于请求报错最常见的是401或403。401一般是后端换authCode时候用了过期的AppSecret或者code已经被使用过。403多为后端IP不在服务器出口白名单里这种情况你需要在钉钉开放平台后台配置后端服务器的出口IP否则请求根本到达不了钉钉的服务端接口。6.2 从微信小程序迁移到钉钉小程序的关键改造清单可能很多团队的第一反应是拿微信小程序代码直接迁。为了减少踩坑我把迁移过程中最容易被遗漏的改动项整理成一张速查表改造项微信小程序钉钉小程序模板指令wx:if / wx:for / wx:keya:if / a:for / a:key样式尾缀.wxss.acss布局文件后缀.wxml.axml全局API前缀wxdd登录接口wx.logindd.getAuthCodeHTTP请求wx.requestdd.httpRequest本地存储wx.setStorageSyncdd.setStorageSync数据监听observer / setDatasetData无observer或需自行实现用户信息wx.getUserProfiledd.getUserInfo依赖通讯录权限文件下载wx.downloadFiledd.downloadFile 获取下载信息接口分享wx.shareAppMessagedd.shareToChat配置文件名project.config.jsonmini.project.json这张表只是最基础的清单真做起来还要逐函数排查。比如微信的wx.showToast支持icon参数里的loading、success、none钉钉的dd.showToast类型名称可能变成success或fail你传一个微信风格的枚举值进去钉钉可能直接忽略图标设置。多个团队实测下来一个中等复杂度的页面大约二三十个交互逻辑、十几个接口调用从微信迁移到钉钉纯搬代码加调试如果是熟练开发者大概需要三到五天。如果页面涉及审批、考勤、外部联系人这些特有开放API工期还会翻倍。6.3 权限、白名单和组织身份校验的坑最后一个大坑是组织身份。钉钉小程序天然自带To B属性但你写的应用可能会同时被很多不同企业安装。也就是说同一个后端服务要能清晰地识别出“当前请求来自哪个企业、哪个员工”。如果你只是用userId做数据隔离不去校验corpId很有可能会发生传说中的“越权问题”——同一个userId在不同企业里指向的是不同的人串号之后数据就乱了。我的处理方式是统一在后端维护一张“企业成员映射表”以corpId userId作为联合唯一键每次请求都在中间件里校验这个联合键是否有效。同时定期调用钉钉通讯录接口做增量同步保证离职员工及时从表里移除。这个设计在微信小程序里几乎没有对应物但在钉钉里属于必须要处理的问题。7. 怎么选写给产品经理和技术负责人的决策建议如果你的目标用户是普通消费者、你需要的用户规模是百万级、你需要裂变分享和微信支付这类能力选微信小程序没有任何悬念。如果是一个企业内部的管理工具使用人群是本公司员工或者客户企业的员工核心业务流程涉及审批、考勤、日程、组织通讯录那么钉钉小程序的优势极其明显——身份免登、组织数据、审批集成都是平台原生能力你不需要自己做一套账号体系和权限树。假如你的产品走的是“企业服务SaaS”路线想卖给很多家企业那么你大概率需要做成钉钉生态里的第三方应用。这时你就要重点研究两个模型企业内部应用和第三方应用。两者的接口权限、上架流程差别很大内部应用开发起来更简单但只能在一个企业范围内使用第三方应用要走应用市场审核同时要适配多企业定制化配置复杂度要高不少。从团队技术栈规划角度讲如果未来一年内只有钉钉一种To B侧需求就专注原生开发。如果两种都要覆盖那就要评估业务里平台API的使用深度。纯展示类、轻交互、不做复杂数据上报的东西引入多端框架是正确的。而业务一碰审批、支付、模板消息这类深水区还是老老实实分开维护两套代码。我个人在实际操作中的体会是不要在项目早期把“一套代码多端覆盖”想得过于美好。微信和钉钉的表面语法差异其实通过一些组件封装就能抹平真正抹不平的是平台背后的组织关系、身份体系和审核流程。这种差异从技术栈一直延伸到产品设计是没法靠工具链彻底弥合的。你在选型那天多花一上午想清楚核心用户在哪比后期省下的三个月的迁移成本划算得多。