前端圈对状态管理的执念，可能是过去十年最大的集体焦虑。从Flux到Redux，从MobX到Recoil，从Context API到Zustand，每隔一两年就会冒出一个"更简洁"的方案，然后大家又开始新一轮的重构和争论。

但我越来越怀疑一件事：我们在用前端的方式解决本不该存在的前端问题。

状态管理焦虑的根源

大部分前端开发者第一次接触Redux的时候，都会有类似的困惑：为什么一个简单的计数器需要写这么多代码？action、reducer、dispatch、connect，整整一套ceremony，就为了让组件拿到一个数字。

当时流行的解释是："这是为了可维护性。" 等项目大了你就懂了。

确实，等项目大了，我懂了。但我懂的不是Redux的好处，而是我们把太多不该放在前端的状态放在了前端。

举个真实场景：用户的投资组合数据。

前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。

这不是技术倒退，而是对"分离成本"的重新认识。

前后端分离的三大隐形成本

大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。

1. 沟通成本：从「对话」变成「会议」

以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。

前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。

我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。

金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。

这不是技术问题，是认知问题。

博客是放在Amazon的EC2.

全程参考：http://imcn.me/html/y2012/11870.html

其中遇到文件权限的问题：

默认EC2的nginx和php-fpm的用户和用户组是www-data。但是我ubuntu的文件权限是quentin，所以php写文件没权限了。

所以为了使php-fpm和文件权限一致，配置如下：

修改php-fpm配置：sudo vi /etc/php5/fpm/pool.d/www.conf

user = www-data 改成 user = ubuntu

修改nginx配置：sudo vi /etc/nginx/nginx.conf 

user www-data 改成 user ubuntu

前言：

MySQL的备份/恢复(导入)命令一般使用如下：

备份：

mysqldump -uUSERNAME -pPASSWORD DBNAME > FILE_BACKUP.sql

恢复(导入)：

mysql -uUSERNAME -pPASSWORD DBNAME < FILE_BACKUP.sql

注：

• USERNAME  - 数据库用户名。如：root.
• PASSWORD - 数据库密码。如果为空空格即可，或者不写 "-p" 参数。
• DBNAME - 数据库名。
• FILE_BACKUP - 备份到文件的文件名。

这样就实现了备份和恢复。

乱码问题：

但是，如果你拿到一份别人或者从网上download下来的sql备份文件，导入之后发现有乱码，怎么办？

一般出现乱码是跟导入时的编码相关。其实很简单，导入或者备份时加一个参数（--default-character-set）就可以避免编码问题的发生。

如：

备份：