版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/YQXLLWY/article/details/79256833
防止tp框架在update表时报错
我们知道在对数据库进行update操作时如果对表数据没有进行任何修改时是会报错的，而当我们将结果返回给用户时，用户肯定不知道是因为他没有进行任何操作导致的报错，他们最直观的反映就是系统出错了，接着就是一片惶恐。
所以为了防止上述情况的发生，可以试着在表结构中添加一个update_time字段，每次updtae时获取当前的timestamp，这样可以保证用户每次的编辑都成功。
modal的爱恨情仇
这个纯属于我个人的意见，那就是在modal中不要封装该modal 之外的表的数据处理，除非是与该modal一体的数据，即主外键关系，因为虽然你可以将所有的业务逻辑处理放在modal中去实现，但是导致的结果就是这个modal的利用率很低，面对越来越多的需求，导致代码越写越多，这个modal也越来越庞大，牵一发而动全身。
返回错误与前端容错
这个也是一个习惯类的东西，比如后端进行业务逻辑处理时确定对某个变量返回给前端的结果是false，那么前端如何来保证后端返回false后也能正常运行而不报错呢？
/**
* 假设后端返回结果是：
* 正确结果：
{
name:[1,2,3,4]
}
* 但是由于name为空，所以返回 false
{
name:false
}
**/
fetch("",{credentials: 'include'})
.then((response)=>{ return response.json(); })
.then((responseData)=>{
// 这里添加一个 || 的容错符，当前面的值是false时，程序也能正常运作
let name= responseData.name || [];
})web端与移动端接口是否可以公用？
理论上来说不会有很大问题，但是至少以我个人的经验来说我不建议这么做，因为一个很现实的例子就是当后端返回300多条数据给web端的时候，web端没有任何问题，但是提交给移动端后，移动端直接炸了，当时写的是微信小程序，直接报渲染层出现错误，而为了防止这个问题并且不重新再写一个接口，所以就在原始接口中加入了分页的功能，并且需要保证对原始接口不会产生影响，所以针对web端接口与移动端接口是否可以公用这个问题，我个人意见是如果是小数据接口，那么没有多大问题，但是大数据，即使是为了以后web端优化而添加分页也好，建议是重新写，或者在写之初就加入分页的设置。
当然问题不止这些，还有很多，接下来会专门针对这个问题写一篇博客的吧，应该吧。。。。。。