webdav 挺好，ftp 也还行，这两个可以出局域网。smba 不能出外网，但也有折中方法，使用 frp 反代到 vps 做挂载盘也是可以用的。

前端的知识更新太快，一味追求最新的技术其实没有什么卵用，无非就是重复的造轮子而已，个人感觉如果不是扎根业界，够用就好，不必最新。一个可以直接 js+css 写出来的代码，在我看来什么框架都不用最好。

没有冲过任何钱给腾讯，就淘宝买了个一块钱的备案码，腾讯客服自己打电话上门帮忙备案什么水平？

Nginx 是默认位置吧，至于网站则放在了挂在盘里面，防止系统崩了之后丢失资料（用 vps 养成的习惯，以前用过的一台 vps 特别烂，三天两头崩溃）。同时还写了个脚本每天零点自动备份数据到另外一块硬盘上。

不写注释才爽好吗…只是后期看代码就蛋疼了，你让任何程序员不写注释都能做到的，后期维护就不知道了，至于你说的情况，我觉得可能是留了两份吧，开发用开发版的有注释，上线了就删除所有注释，提高阅读成本。一般搞前端的比较普遍。

@iwtbauh 74#受教了，以后有需要的情况下也有可行对策了，虽然有轮子用自然最好了的，pdo 也挺方便的。但多一个办法多一条路总归也是好的。

rem+响应式吧，分辨率不是问题，只是不再兼容 IE9 以下了。

已重写控制程序，目前使用 pdo 预处理解决注入问题，今天一点开就 40 多条回复，没想到那么讨论激烈。其实这个被疯狂吐槽的需求锅不应该由我来背。。。因为之前的数据库控制程序并不是我写的，项目做到一半由我接手的，现在想想的确挺蛋疼的，之前的控制程序直接是标准的 sqlite 接口，当然也有一些基本的字符串过滤，但感觉不太好，但也因为怕出 BUG 实在不想改数据库控制程序这部分，所以才想了一些投机取巧的方法。后来一想长痛不如短痛，索性都重写了，好在业务逻辑也不复杂，已经全部搞定了，感谢大家的意见。

@Vegetable 没有复杂查询条件我觉得是可以的，但碰到如果有模糊查询就不行了。我目前需求只是偶尔有一些精确匹配搜索，所以问问可行性，没想到那么多人理解错了，哈哈，没关系。实在不行就老老实实的直接做标准过滤吧，反正也就是处理一些用户名、密码、数量、型号、日期什么的，按照它们的类别做好过滤即可，一般也用不上这些特殊字符，保留英文数字，正则判断禁止所有的特殊字符就可以了。

@opengps 好的，谢谢，我认真考虑你说的方案的。

@yagao0o 是啊，我也这样考虑了，这个问题比较困难，虽然目前数据库虽然没有模糊匹配的需求，但以后就不确定了，所以也只是探讨一下是否可行。

@gamexg 恩，你说的很对，我也考虑过。不过目前我数据库需求，都是完整精确匹配的，可以将输入内容也进行 b64 预处理后再搜索，类似于 MD5 的密码校验吧。复杂的多条件估计是不行的。所以也是处于考虑中是否要这样做。

@funcman =_=神奇。。好吧，看来我说的不清楚，大家都有些理解错误。我的意思在明确一下：字符串处理完全在后台存数据时进行，存入到数据库的就是 b64，SQL 增删改查的关键词都是预设的字符串，固定的，前台来的变量则通通都会被编码成 b64 再存储，网络传输阶段都是明文传输的，和传输阶段没有什么关系。

想不通为什么大家都理解为传输阶段进行编码呢。。我的意思其实是存入数据库前由后台进行编码，存入数据库的就是 base64 内容。

@Greenm 前台拿到的数据是明文字符串，到后台存入数据库前，进行编码后再存入数据库。需要时再取出来，然后直接解码还原。

版本 6803440，无法复现。

@jookr 国内机房普遍都有白名单机制，会过滤进入 80 端口的所有流量，如果不在白名单的话，拦截的拦截（直接报错），跳转的跳转（强制转到备案提示页面），流量不会到达你的 nginx 或者 apache 服务器上，所以你自己服务器上的跳转规则是不生效的，但好在主机商一般不会拦截 443 端口（人家也是要恰饭的，一般都睁一只眼闭一只眼），所以直接访问 443 端口是可行的，但回到主题，如果想要从 80 直接跳转到 443，那是做不到的（因为刚刚说了，请求没有到你的服务器就被处分掉了，所以你的规则不生效）。除非上 HSTS 在浏览器阶段就自动跳转，那是可行的。

NAT 了吧，你的 MAC 有公网 IP 吗？没有的话肯定是不行的。只要上级路由禁 ping，肯定无法 ping 通。