今天给各位分享微信小程序开发到web的知识，其中也会对微信小程序开发到上线进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、一个小程序的后台是web端
- 2、嵌入已有的 Web 页面的「Web」小程序和使用微信小程序框架开发的「原生」小程序相比，有哪些区别呢?
- 3、微信小程序web-view ， 嵌入H5页面
- 4、微信小程序需要哪些开发工具
一个小程序的后台是web端
小程序
第一个web项目-微信小程序后端开发

第一个web项目-微信小程序后端开发
前言
需求分析
团队分工
总体设计
开发工具及编码实现
小程序前端
后端
数据库
接口代码
管理系统前端1.0
管理系统前端2.0
测试
后端本地测试
前后端联合测试
部署
总结
第一个web项目-微信小程序后端开发
前言
去年暑假一个偶然的机会我和几位同学加入了学院一位老师主持的教改项目，需求是开发一个基于SPOC与翻转课堂的计算机组成原理课程的学习app（类似慕课、知到），后来经过讨论决定降低难度，先做一个微信小程序，附带一个后台管理系统，于是我的第一个web项目就开始了~
需求分析
这里简单介绍下SPOC和翻转课堂的意思
翻转课堂
“翻转课堂”（Flipping Classroom）是一种颠覆传统教学由“课堂授课听讲 + 课后作业练习”转变为“课前自主学习 + 课堂协作探究”的新型教学模式。
SPOC
SPOC（Small Private Online Course）一般被译为小规模限制性在线课程或者小规模私有型网络课程，音译为“私播课”。
这次项目的需求是开发一个学习类型的小程序，用户分为学生和教师，其中学生可以观看视频、课件、动画，完成作业、考试以及发布评论、点赞、回复，而教师可以上传教学视频、课件、动画和发布作业、考试、通知，以及查看学生的学习情况，也可以查看评论回复，及时解答学生的疑惑。
团队分工
团队一共有四个人，总体工作分为产品设计、前端开发、后端开发三部分，然后每部分由两人负责。其中我是负责后端开发的，同时兼任项目负责人（其实也没有听上去那么高大上，只是需要承担更多决策、协调、沟通的角色）。
总体设计
这里分为小程序和管理系统
首先是小程序，放几张使用墨刀制作的原型图，这里多说两句，市面上的小程序基本都是微信授权直接登录，最多绑定手机号，我们这个由于要统计学生的学习情况才设置了注册和登录功能
至于管理系统，由于是10月份才开始做的，而且是我和另一位做后端的同学负责的，时间比较紧，我们作为前端小白没有十分系统的方法去做开发，只是大概确定了需要做哪些模块，每个模块对哪些表的增删改查，这里原型图就不放了（较简陋）
开发工具及编码实现
小程序前端
据我了解，做前端的同学先去微信公众平台注册账号，然后做一些开发设置，具体步骤自行百度。前端用的是微信开发者工具，有不会的基本上在微信开放文档都可以找到，包括许多实用的API。
后端
这里分为数据库、接口代码两部分
数据库
用的是mysql数据库，之前是跟着学堂在线的一个小程序入门教程做的，它推荐的本地开发环境是phpstudy，里面集成了php、mysql、apache、FTP、Nginx以及数据库管理工具phpMyAdmin，关于phpMyAdmin使用请看
原本的数据库设计得不好，存在较多冗余数据，后来学习了数据库系统这门课，我进行了大改，先确定有哪些实体以及实体之间的联系，然后画er图，最后再建模，通过外码约束大量减少了冗余，也减少了表的数量。
接口代码
教程使用的是php语言，框架是thinkphp5，开发手册看，我当时是去b站找视频学了下php基础语法，然后就去学原生php以及框架如何操作数据库。然后根据业务逻辑开始编码，其实每个接口（或者叫类里面的一个函数）结构都差不多，主要是三部分：接收前端传来的数据、增/删/改/查、返回结果给前端。
顺便说下代码编辑用的是sublime text3，教程看，这个不是ide，没有那么多的功能比如调试、运行，单纯是只有编辑、加注释、格式化等等，这里吐槽下自带的格式化代码功能（先选择代码，再Edit – Line – Reindent），有点辣鸡。而且如果有语法错误不会像eclipse那样自动检测出来，之前被坑了几次，肉眼找不到的话只能用postman去测试了。
管理系统前端1.0
一开始我们是不知道还要做个管理系统的，以为所有功能都放在小程序，后来老师跟我们讨论聊到这个问题，我们才知道原来还有这回事，其实就是管理系统应该具有一切功能，即对数据库所有表的增删改查，而小程序只需要有些轻量的功能即可，至于上传大容量文件、查看学习情况这些不够轻量的功能全部放在管理系统。好吧，凡事总有第一次，我们就开始学习基本的前端三件套html,css,javascript。
开始做的时候我们希望先实现功能，界面难看点没有太多关系，于是学了部分三件套的基础后又学了ajax技术（因为要与后端通信），这里最开始用的是创建XMLHttpRequest 对象，用open()方法设置请求类型和url，用send()方法发送数据到后端，直到遇到了jquery，后面的请求统一都用$.ajax()了。
接下来又遇到了一个难点，因为基本都用表格来展示数据，那获取数据后如何动态地加入表格呢？查找资料后用每一条数据拼接成由tr标签包含的字符串，然后用jquery获取表格标签后调用append()方法加入表格中。
除此之外，我们想在每行末尾设置按钮进行事件处理，于是我们append数据的同时也把button标签放入刚才的字符串中，然后给每个button设置id属性，比如用于修改数据的就叫fixi，最后这个i是代表表格第几行，然后添加事件监听，点击button时获取id，然后查看最后一位是多少从而确定是第几行。
这些做法实现起来是挺繁琐的，而且感觉在重复造轮子，我们也做得有点郁闷，因为每个页面基本都要这样做，但是当时没有那么多的时间精力去学习框架，只是想先实现功能（u1s1，上学期的课多到我快吐了）。
放两张界面图
管理系统前端2.0
之前放假，总算有较多空余时间了，我们决定要改下界面，但毕竟自身水平不高，因此需要用一点第三方的东西了。
在跟小程序前端测试了部分功能后，有一天后端同学找到了一个开源的框架然后我们一起看了下说明文档，最后决定：就用它了。
有请layui登场，经典模块化前端框架、低门槛开箱即用。
真正使用之前可以先看看文档，个人感觉上手还是挺快的。layui提供了许多实用的组件包括弹出层、表格、表单、文件上传、流加载等等。
就拿表格来说，之前我们用append动态添加数据，现在直接table.render()，设置好参数就行了；之前我们给button设置id进行事件处理，现在绑定工具条，直接table.on()就行了；而且之前我们没实现的分页，现在设置分页参数就行了，然后查询数据库时分页读取。
另外，layui提供了一个页面布局的模板，包括logo、用户名、退出按钮、导航栏以及一些css动画。我们要做的就是按照它的模板来，页面元素的样式也参考它提供的。
有了layui的助攻，我们可以将更多注意力放在业务逻辑上，更多关注用户体验。
测试
后端本地测试
工具：postman
使用：打开一个新窗口，选择请求类型，输入url，设置参数，点击send
这种测试我认为是模拟前端发送数据然后运行后端代码，看结果是否正确，属于白盒测试，但是我们不是专业测试人员，目前这样测试不是做得很规范，只能尽可能想到不同的测试用例。
前后端联合测试
由于放假回家了没办法面对面，只能借助腾讯会议线上测了。
在部署工作完成之后，一般是我们写好接口代码，然后把url和需要的参数告诉前端同学（这里注意下，微信小程序的请求api只允许https开头的url，而且前端必须在微信公众平台配置好合法域名，不然会报错），前端把这些东西填入那个wx.request的api然后运行，他们会查看返回的数据是否正确，我们会查看数据库的情况，如果没问题会测试多几个数据，都可以的话就到下一个功能，这种方式应该是属于软工讲到的V模型的单元测试。
部署
用的是新浪云，实名认证、学生认证后会送一些云豆（新浪云的计费单位，1RMB=100云豆）
跟着之前说的教程把整个thinkphp项目部署到新浪云，具体步骤看
代码
在代码管理那里可上传压缩包，或者在线编辑（跟记事本差不多），改动大的最好在本地写好再贴上去
数据库
开启共享型mysql服务，目前用了phpmyadmin4.9版本，然后建表或导入sql文件
缓存
开启memcached服务，设置容量16MB（省点钱），其实这个服务我不是很清楚干什么的，但如果不打开访问接口时会报致命错误？
文件存储
我们需要保存许多类型的文件包括视频、课件、动画、作业、考试、头像，因此需要存放在服务端。这里开启storage服务，使用方法看，普通用户配额5个bucket，每个容量10G，然后直接当作本地磁盘那样用就行了，控制台或写代码都可上传文件，上传后获得url，然后就可以通过网络访问，关于新浪云环境下php如何操作看官方文档。
域名
应用信息可查看二级域名，独立域名需要购买且备案
日志
日志中心可查看每次请求的接口、时间、请求方设备等信息
其它
控制台还可以实时查看流量统计、资源使用情况，以及消费情况
总结
这个项目我也算前后端都做了一遍，感觉前端不太适合自己，可能是对页面元素样式、用户体验不够敏感，不过必须承认前端是挺有意思的。至于后端是更加注重逻辑，目前我对后端的了解只停留在数据库、网络、部署层面，其实如果用户数量非常多还要考虑高并发的问题，也就要使用多线程、负载均衡、消息队列等技术了，所以还有很多技术需要学习
嵌入已有的 Web 页面的「Web」小程序和使用微信小程序框架开发的「原生」小程序相比，有哪些区别呢?
在这之前，如果有人问我，在微信中做一个产品，是用小程序还是 Web 页面 (严谨，既不是 HTML5 更不是 H5…) 的时候，我会这么说：
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
关于后一点，朋友圈分享现在普遍会用海报来做，在这点上 Web 和小程序的能力其实是一样的，都是只能帮你保存图片到相册，再请用户手动发送到朋友圈。而小程序独有的发现 – 小程序、搜索框快捷方式等对用户回访特别重要的入口，Web 页面是不能使用的。
那么，昨天的发布意味着什么？简单地说，小程序的开发成本有了很大的下降。
微信小程序刚刚上线的时候，由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发，让一些媒体误以为小程序就是 Web 开发，欢呼将「迎来 Web 开发的春天」。我自己的第一份工作就是 Web 开发工程师，Web 开发入门确实比较容易；可是尽管小程序使用了 Web 语言，那只是语法上的一致，整个开发模式完全不同，更接近于原生 App 的开发而不是 Web。打个比方，对在看这篇文章的大多数人来说，读中文要比读英文更容易，但假如你看不懂英文版的《量子力学导论》，翻译成中文版你也不一定能看懂。开发小程序，需要有专门的、独立于 Web 团队之外的团队，按小程序的规范重新设计、重新开发，不能将已有的产品直接迁移过来。
可以理解微信当初做这个决定，是希望开发者按照微信的要求，为微信的用户重新去思考、设计一套全新的用户体验，而不是将已有的 Web 页面搬进来。历史上，包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险，而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章，解释为何 iPhone 不支持 Flash (Thoughts on Flash)，其中最重要的原因是，Apple 不希望第三方开发者将已有的产品直接搬过来，而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发，为 iPhone 的用户提供最好的体验。这些决定赌的是，新平台 (小程序或 iOS) 带来的商业上的好处，最终会让开发者们愿意付出这个成本。
那时候的 iPhone 还很弱小，但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布，将在 2020 年最终停止 Flash 的更新和分发。
微信，则在昨天支持了开发者直接嵌入已有网页。
所以，如果你已经有一个网站，可以直接在小程序中套个壳，把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
细心的你可能已经注意到了，上面这两条并没有任何变化… 对，在小程序的用法上其实没有任何变化，只是开发成本下降了。
那么，在今天之后，使用微信小程序框架开发的「原生」小程序，和嵌入已有的 Web 页面的「Web」小程序，在用户感受上会有什么区别呢？
「原生」小程序，整个小程序是提前下载的，不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明，这是用户对一个界面是「Web」还是「原生」的最主要判断标准。对于偏工具型的小程序，「原生」的感受应该会更好。
「原生」小程序对体验的控制更完整，自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制，而在「原生」小程序界面中，这是需要单独添加的功能。
「原生」小程序提供了一些专属的控件和 APIs（接口），如展示群信息、发送推送等，这些只有使用小程序框架开发才能使用。
所以，如果需要和微信生态整合得更紧密，可以使用「原生」方式开发；如果追求快速迁移已有 Web 产品，嵌入 Web 页面更快。
微信小程序web-view ， 嵌入H5页面
需求：
1、将已开发好的H5页面，嵌入先有的小程序。
2、并且要实现H5支付功能
解决方式 ：web-view
1、 登陆 小程序管理后台
a . 如果是公众号 。则进行双向绑定
完成这一步 ，那么基本上就差不多成功了一大半
2、在小程序里面嵌入h5
web-view
文档里面有的东西，就不赘述le~
a.在小程序里面定义一个你想要的H5入口
b. 新建一个页面，用来放H5的链接
ok~现在已经完成h5的嵌入
3、h5实现支付功能 – 唤醒微信支付
目前只有这种实现方式。等待微信更新 支持小程序的web-view可以唤醒微信支付
总结：
个人见解： 微信内置浏览器， 打开微信公众号H5页面，也可以唤醒微信支付。微信小程序里面web-view相当于小程序的内置浏览器，暂时不支持唤醒微信支付。虽然小程序是在微信里面，但是web-view又和微信内置浏览器不同~ 感觉微信想把小程序独立出来~
微信小程序需要哪些开发工具
微信小程序需要哪些开发工具?
一、微信小程序官方开发工具
注意，它只是个工具，而不是一个IDE。官方工具中的代码编辑功能，就是将vscode的代码编辑功能嵌入到工具中，不足以支撑开发。
优点
因为是官方工具所以有这其它第三方工具有这不可比拟的天然优势，如果不是他代码编辑功能太弱的话。
官方工具，可调试，可预览
基本的代码编辑、智能提示、调试等功能都有
项目管理、创建、手机预览、代码提交审核
官方维护更新
缺点
不好的地方也很明显，总体而言是一款工具而不是IDE。糟糕的代码编辑功能，写起代码非常别扭，这是我放弃它的最重要原因。
api提示不全，要一个个查api，影响写代码的速度
很多必备的快捷键都没有，比如全选关键字、快速复制一行等等
颜色主题不能选，不喜欢白色风格怎么搞
没有插件 没有插件 没有插件 重要的事情说三遍
评价
目前因为需要用到微信web开发工具进行小程序的创建、调试、查看、预览、上传，所以这个工具必不可少。但是代码编辑功能实在太差，推荐使用其它第三方代码编辑工具代替。
二、即速应用——适合技术小白的小程序开发工具
严格来说，即速应用并不是为专业程序员准备的开发工具，但它绝对是一款功能非常强大的微信小程序制作工具。不懂技术不懂编程的人，一定会爱上即速应用这款工具的。
优点
可视化操作，直接拖拽组件生成页面
提供大量可套用的模板
可将代码打包下载，直接对接到小程序的开发工具
下载下来后的代码可以任意编辑
缺点
电商模板居多，其他类别的模板较少
复杂的功能仍然需要专业程序员二次开发
评价
客观地说，即速应用这款微信小程序制作工具非常适合技术小白。因为它相当于把需要代码的`部分都帮你做好了，所以不用太头疼技术方面的问题。当然，如果你是程序员，一样可以在它生成的代码基础上进行二次开发的。
三、Sublime Text 3——简洁高效的开发工具
sublime text 3定位于代码编辑器而不是IDE，在代码提示方面只能算一般般，不过胜在使用起来非常方便。
优点
打开文件速度倍儿快、UI简洁大方
代码编辑体验舒适、高效
拥有大量插件，针对不同需求基本上能找到对应插件来满足
第三方开发者开发小程序插件用于代码着色和代码提示
缺点
没有调试，没有预览
因为是第三方开发者编写的插件，代码提示也不是非常全面
评价
使用门槛不会太高，可以迅速上手。是但如果想实现一些丰富的功能就会比较吃力了。
四、WebStorm——功能繁多的重度开发工具
WebStorm网上有个插件，可以实现代码提示，不能做调试和预览，并且属于重度工具，如果你是，可以尝试一下这个工具。
优点
有插件可以实现代码高亮，代码提示等功能
有非常成熟和非常丰富的功能
各种快捷键
缺点
无法调试预览
功能比较多、比较臃肿
评价
Webstorm和上述几个工具相比，代码编辑功能较强大。但是需要插件支持才可以开发小程序，而且体积臃肿。
微信小程序开发到web的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微信小程序开发到上线、微信小程序开发到web的信息别忘了在本站进行查找喔。
