看业务需求，一般没有防火墙处理的话，VARCHAR 即可，因为你业务上就是把它当字符串用的。

如果整体上没有单元测试的风格，那么本地单元测试，要比不停的“修改——部署到测试环境——测试——修改”循环，消耗的时间更多。因为测试代码你不但要从零开始些，而且用完即废没法长期用。

如果你用过 Windows Phone / Windows 10 Mobile ，你就会知道微软的跨平台只能呵呵。不管是出于成本，还是出于知识产权的考虑，微软跨平台的一贯策略是自己做架子，然后让社区 /对手去实现。虽说确实是开放，但是社区 /对手哪来的动力去实现，结果必然是 Alpha 版本都出不来就 GG 。

根源：SQL 本身就是弱类型语言，MYSQL 又是特别“聪明”的数据库，所以会比 HTML 、JavaScript 这些语言更变态的自动纠错。

对于你的问题，CREATE TABLE 、ALTER TABLE 、ADD INDEX 这些，只是一次性的动态执行语句，它们不是数据库物理模型的最终的定义语句。故，类型不一样，同样的逻辑有些能执行有些不能执行，这都是正常情况。

最后提一点，对于日期时间、或者时间戳类型，建议不要在数据库上设置默认值，坑太多。NOT NULL 但是没有默认值，这是允许的。

双币卡是磁条卡，现在已经不让申请新卡了（老卡想用可以继续用）。国内的信用卡是单用户审核，你在一家银行只要激活了任何一张卡，那么所有非特殊卡都能任意申请。随便申请一张银联卡，激活后再要一张全币种卡就可以了，现在 VISA/MASTER 单通道全币种卡基本都是全免费的。

国内的信用卡卡种起始不重要，同一家银行的不同卡，基本上就实体卡长得不一样，后台是一摸一样的。信用卡是长期使用的，国内还是典型的老用户不如狗，所以各种申请优惠，要当成锦上添花的东西去看，不要作为比较指标。

下载文件时的消耗的网络流量，受网络协议、压缩协议、文件大小等多方面因素影响。

不公开的实践项目会很多，但是公开并且规模还足够到可以学习的案例项目，不可能有，别找了。

另一方面，DDD 不只是编程思想，它是涉及需求、交付、开发、测试等全方面的开发思想，如果不能在客户、产品、开发之间形成通用语言的话，那也是用不了的。你可以拿公司的非紧急项目给自己练手用，不要想用 DDD 单方面去解决公司的项目开发困境。

并不是不安全，而是做不了。可以把手机关机都能刷的那个卡人为是普通的公交卡 /门禁卡，把电子钱包看成写卡工具。卡在你手上，读卡的东西还在公交公司 /门禁那里，但是写卡工具控制在手机开发商那里。各种卡想接入手机钱包，都是要给手机开发商上贡的，而 Apple 索要的上贡量，是连二三线城市的公交公司都承受不起的。

锂电池满电亏电都特么损耗，容量小的锂电池，能撑到过保就很了不起了，过保了就只能当废物处理。现在这种电池情况，无限耳机都是一年期消耗品，哪怕它很贵。

3D 电影回归 2D ，Kinect 这类的体感游戏在 VR 游戏接棒之前就消失，Hololens 贵得要命还只提供给开发者。有这些前车之鉴在，别说办公领域，就是游戏领域和娱乐消费领域，VR/AR 离真正能用，还远着呢。

FCM 的机制就是推送消息拉起应用然后交给应用处理，应用可以不常驻后台，但必须能被后台唤醒和后台执行。Android 通知中心对接的是本地应用不是 FCM ,不要妄想 IOS 那样可以抛开应用直接对接推送服务的通知中心。

找个轻量级的 ERP ，或者整理好需求找外包做软件。虽然都不便宜，但是人数越来越多的情况下这钱得花。

@DinnyXu #4 那就没辙了。跳板机那个做不了的，因为 VPN 客户端不一定支持你让它当跳板，更别提还有深信服这种带监控的 VPN 。

单独弄一个电脑做 VPN 客户端即可，用得时候装，用完即卸载，或者干脆跟网吧一样上还原卡。也可以用虚拟机代替单独电脑，但有些 VPN 在虚拟机上可能没法装。

要是钱够的话，可以每个项目都配上一到几个电脑专门当 VPN 访问用。

这个跟之前那个互助是一样的，是商业行为，不是保险。但是保监会要是想禁止就有权限禁止，因为是不是保险是保监会说了算。不过这种小玩意金额不大，没闹大保监会也不没心思去管。可以试着向保监会举报一下，说不定就碰到那个热心肠的愣头青会管一下。

@ysc3839 #12
Android 的应用权限管理，也就是个应用权限管理，有那么点安全，但整体安全性是个屎。本主题讨论的是跨应用文件保护问题，这点上 Android 连它基于的 Linux 的用户文件隔离都没有，根本没法保护。而就算 Android 官方系统把应用沙盒特性给做好了，OEM 可以不上这个特性，各种国产 APP 有各种方式可以绕过这个特性，在 Android 这种非封闭生态下，安全性需要多方协作才能保证，光靠操作系统一方根本不可能保证。

第二段，说了那么多没说到点上。第一，UWP 可以不适配移动端，只适配桌面端的 UWP 多的很。第二，Win32 API 从来没有被砍，它的限制只是不能上架商店，以及不能使用 Win10 新增的相机、位置这些移动端才需要用的 API 。第三，UWP 的失败，主因是它能被自家的 Win32 应用或 Web 应用随意替代，换句话说，是因为 Windows 生态太开放。

虽然苹果在硬件指标上确实溢价高还扣，但是 6G 内存还狂杀后台，也真是不怕闪了舌头。

@ysc3839 #9 苹果的生态都是靠封闭来控制安全的，Windows 跟 Linux 系压根不可能用那种方式。纯 UWP win10 商店前车之鉴。而 Win10 mobile 前车之鉴也决定了微软短期内不会抛弃现有的 windows 生态去另行搞一份类似 macOS 的生态。

“谁编码谁负责”可不是让你这样搞的，结对编程或者相互代码评审才是保证代码风格的途径。你这样搞是 5 个独立的人在开发，不是 5 人团队在开发。