一种设想：打造小程序版本公号和自托管的公号，将你的网站/blog做到微信/微信公号里且与PC端合一

本文关键字：打造小程序版本公号，打造微网站版本公号，,从私有云到私流，微信移动生态，微信开发者号注册，将你的网站做到微信，微信blog微网站/小程序,将认证后端做在网盘中,，将你的网站小程序化weapp化,wxamp化,cloudfunctions与miniprogram的绝配

在《mineportal：个人云帐号云资源利用好习惯及实现》中我们提到，id和用户身份是统一产品和运营生态的开始,而opensocial id之类的sns不争气统一不了标准。手机上也没有google id，appleid，移动手机号这样的入口标准，因此这项任务被拥有海量用户的app所占据，比如微信，微信有海量用户，,由于微信客端自带浏览器所以也可当微网站客户端用（只是从微信跳出或跳入），所以它将其分给能起运营作用的用户app或网站调用(除了用户接入服务还有其它，比如支付服务)，，让运营做到每个人的手机里，与以前的pc网站和pc网站运营是对等的。只不过这次这些转移到了手机上而已：移动端对应的是微网站和寄宿的自媒体号。比如微信公号。，这类产品还有开放平台。

微信/微信公号和开发者号：一个产品，一种身份

来看下这个“微信公号”，微信公号实际上是腾讯利用自己的资源自己运营的微信”内挂小程序/微网站”，用户只需提供内容，当然，单有一个发布内容的地方是不够的，公号下有很多默认功能扩展，还允许利用开放平台对公号进行功能扩展，微信公号自带很多扩展，除此之外，用户还能建立自己的微信小程序。用户开发的小程序是外挂式的(下拉显示在微信头部)，由于微信小程序/公号小程序/用户小程序/内欠到微信的微网站这四者共享同样的微信环境和微信运营资源。微信微网站/app/公号开发的基础和原理/技术实现/功能作用范围也是一样的，实际上都是一样的。比如你也可以发明一个更高级的留言程序创造相似的功能代替公号内官方那个留言，或一个微商城级别的程序或者租第三方微信服务商城里的服务仅需要一个ticket。而政策上，腾讯当然会限制或监管使用这些API的主体，比如用户程序或网站毕竟来自非微信的外部逻辑和安全上必需这样去做。面向开放的是个人还是企业,还要视api的重要度也要去设层保护，比如为了保护内部支付服务调用仅对企业开放这是必要的(而共享他们的用户身份oauth可以给任何个人)，(我们知道做站注册域名，工信部都需要监管一层)。

所以，腾讯还设立了微信开放平台和微信开发者号，辅助用来对微信小程序和微信公号开发和统一管理它们的API权限。个人可以注册订阅号和注册小程序号却不允许注册服务公号和企业订阅号也不能注册微信开发者号的。必须至少要用一个个体户或企业身份，PC网站移动应用也只能在开发者号里找到。在开放平台里你甚至可以将小程序授权给小程序开发商，只需获得一个票据就可以使用它们关于小程序的所有功能和托管无须开发纯买卖。（即使可以，用户小程序用户公号的权限和企业的也有区别，申完开发者号后，可以在里面申请开放每个小程序或微网站的api权限，按重要度，获取用户的基本信息这类基础API，对企业和个人的APP和公号来说都无须认证，不收费。涉及到支付等关键领域，还是会要求法人认证的，而法人有更高权限，如开发者版绑定的小程序较个人版本也有更高级权限支持js网页里跳转。），而且开放平台可以汇集帐号下注册的移动应用、网站应用、公众号及其他小程序，关联到开发者号后，将这些通过unionID机制统一用户账号。如果你不用到进阶API或统一uid，公号小程序和公号本身足于满足你对接海量微信用户的需求不必开开发者号。而为了对接独立微网站或PC网站，需要开发者号。 ------ 这样就有2号：微信号，开发者号，(这个还在不断扩展，如商户号)，三件可开发：小程序，移动应用接入/pc网站接入/微网站扩展/公众号、订阅号、服务号扩展，前者是号和主体后者是产品，我们最常用到小程序和pc网站，，注意区别。

注册开发者号的经验：如果是个人，不建议专门为了这个而去办个体户，因为维护成本较高且涉及到征信问题，在某宝上找个个体户挂靠，虽然也有风险，但至多损失的是短期临时的投资（找那种省事提供企业身份且无须年年交认证费和年审费的。现在虽然取消了开发者号年审但也会抽查，有些卖家会以腾讯会定期抽查要求你每年都交被认证方手续费和认证方年审手续费他们将维护一个个体的费用按人数分担到这些用户:腾讯会雇佣第三方来认证无论成功失败都收还很贵300一次不过别担心它有打回重填）如果你找到的比较有信誉，你至少可以用上一年+。分四步，第一步你可以填自己的管理微信（其中的信息只有你的微信认证后才能更改），第二步会涉及到法人主体信息电话回访人脸验证填写，第三（不开票），第四付300初次年审。以后审请网站应用认证的时候，也要用到法人身份和实名域名，还需要公章（个体户没有公章在公章处签名），和网址与主体保持一致,之后可改授权回调域域名无须再审，政策每年都在变，成功可获得appid和secret。审核小程序的时候也要注意，像博客这种小程序应该选择教育 > 教育信息服务

一个更自由的公号环境，小程序还是微网站好

只是由于公号实际上定位于媒体，所以它发表的每一篇都是不可修改的且每天一篇（个人订阅号）即使企业订阅号服务号也是有限制的（它有一个好处是可以开通流量主，再运营），---- 所以不断后台开公号插件和直接利用公号运营，是十分受限的。所以有没有方法打造能够存在于微信里的blog程序，产生和公号效果一样但无限制编辑发送的写文章后台，和打开文章不提醒外域跳转，能被微信用户关注，和能推送到文章和消息到关注用户微信的功能呢（为避免频繁消息可以设置一个可选推送开关）？（PS：以上这些功能缺一不可，都被做成了api，缺一则废。比如少了推送给用户。即使你的内容再精美，用户也不能被动成为你的受众。）最重要的：用户，我们能不能还像公号一样，多平台维护却始终能做到只维护一份共同的用户呢，

要打造自己的微网站托管公号，我们可以配合小程序和公号模拟现在公号已有的全部功能，那些在公号菜单里欠入微网站还能用微信一键登录的。就是服务号或公众号(个人订阅号只能把小程序当微网站用跳一次到小程序界面，或者文章里阅读原文达到)，而且可以实现一样的oauth无感登录注册。但是不能消息推送到微信（因为它来自外部网站）。这种情况下公共号只是一个传手，我们需要托管自己的微网站。这种公号实际是就是一个pc网站blog端的shell，而且微网站的用户和你后端对接到的用户是二份。不过它胜在体验自然。却输在以上方面，且需要法人认证。微网站往往不用开发。难度低。如果对公号开发，又维护了二份成本。

另外一种方法是用微信里的小程序。个人可用，小程序直接寄宿在微信头部，虽然可以欠入公号，但是需要跳出公号。这种体验终归有些不自然。但小程序扩展能力强，小程序可以基于任何目的比如它可以代替公号发布做成一个blog或cms，也可以是一个社区，也可以是其他各种需求的扩展，因为它是个app业务逻辑可定制，（当然，发布的时候，审核会让你选择一个用途。）但小程序往往需要自己开发，（小程序开发加入了太多新的不同于传统网页技术的东西，比如有自己的css和html标准），同样可以微信无感登录，且可与外面的网站后端共享后端，优点是可以维护同一份用户（在unionid的PC网站和小程序下）。

再来谈用户，上面二方案中，我们实际上都逃开了公号的限制而依然利用上了微信的运营资源：用户。我们都维护了一个共享后端，常见的微信扫码登录有几种,用户在微信内使用微信授权登录需公众号接口配置，用户在小程序使用微信授权登录需小程序配置，用户在PC的网页使用微信扫码登录需PC网站配置,用户还可以微信扫小程序码实现网页端登录，（实际上有了开放平台和unionid，我们实现三端合一的针对用户的运营。）------ 其实，用户微信登录后，我们依然不能真正获得并管理这些用户（因为它们都是微信里的，需要转发到微信运营），或者需要进一步（我们只获取了微信用户的名字和openid）再运营把它接入到自己平台并让用户在这里交互，转化。将用户转化成你的私域流量。

故，如果追求功能的自然化和全面化。小程序还是胜过微网站。关键的：后端一切托管在我方，所以我们有机会做更多事情。

在开发上，微信里的上述产品就是web开发的那些套路，比如api后端化，异步调用那些，得租用云主机或云函数来托管你的代码(cloudfunctions与miniprogram的绝配:一个托管前端，一个托管后端,且云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写业务逻辑代码)，涉及到websocket和端口的必须云主机，小程序虽小也是一个前后端完整的app，如web一样本质是一个web或ws程序

这里的技术点在哪呢？ 所谓微信小程序，只是提供前端给腾讯托管。我们需要提供一个纯api后端或服务端渲染网页的的后端（前者是前后端在发布层真正分离，后者是普通动态网站的那种前后端源码层可分离）,前者是前后端完全分离，可能是发布层完全另外部署的gui。如htmlui for aria2，后者是狭义开发上的分离，仅限开发层接口前后端的分离处理。 对现有程序对接入微信api和做成小程序，往往前端需要重新开发，后端只须准备一些对接层和api后端化重写。如果我们的程序本来就是前后端分离的，那么极易转化成小程序版本。最理想的情况下，后端纯api化。不要涉及到用任何服务端逻辑渲染前端的逻辑，前后端只通过欠入html的一条服务url路径来交互。后端仅headless core,前端是cli或html page only。 在《用开发本地tcpip程序的思路开发webapp》中我们谈到过那种前后完全分离，用开发spa的思路写网站的方法，这种方式方法下，实际上就是上面提到用js开发三端app的技术，涉及到vue、react、angular等这些前后端分离框架库所涉及到的文案，与传统jq操作dom的js库写网站界面相比，（我们知道一种gui代表一种appstack，界面就代表一种app方案方式），它更强调用本发native gui和tcpip程序的传统思路来开发web app，微信mobile miniprogram。 当然。这些库也有serverside rendering版本。但依然实现了spa和用协议交互前后端的传统APPDEV方式。 微信有专门的小程序开发IDE。注意其调试功能。也是web开发的那些。

discuz Q是一种微网站，我们也可以将前面的onemanager像fodi一样，后端纯api化，前端处理一切渲染。前后端只通过欠入html的一条服务url路径来交互。如fodi一样。

onemanager可把原来的用户系统加入扫码系统，用户扫码即登录，转化为一个中心用户库（即第二套帐密系统，用户名是自动的，密码可以自己修改）。选择某个微信为管理员。仅有这个管理员可以看到后台。

甚至把私域用户信息做进网盘后端。

(此处不设回复，扫码到微信参与留言，或直接点击到原文)