前端防止不了用户篡改去看越权的页面，这事情是服务端做的，接口上让他请求不到越权数据就好了，一个空页面的泄露也没什么可怕的，除非你把敏感数据写成静态资源了？所以你要是觉得前端的权限控制不够安全，你多虑了，这不是一个前端能做的事情。如果你的问题在于“同样的权限控制逻辑前后端在冗余”这种问题，那么这个控制逻辑必须维护在后端，因为之前已经说过了前端安全控制不现实。所以你要做的事情是请求这个控制数据，然后在 SPA 中应用这个控制。现在的做法就够用了。防篡改就保持一个思路：你做某个防范的代价低于破坏者的代价，就去做。安防就是一个权衡，在各种代价之中的均衡态，不要试图达成绝对安全。

@liygheart 没怼过 ios，我编的 android。可以去 weex 官方文档里面看看加载远程 bundle 的部分，把本地 ios 工程的代码照抄改一下。如果觉得弄不聊这个，就直接用 playground 扫码吧。weex debug 开启一个 web debug server

@liygheart 你运行 weex 的 native 壳用的是自己编译的还是 playground?

额，可以把 weex 的加载写成来自 http 的，pc 上面随便弄一个 server 服务起来编译好的 bundle，不是很简单吗？这句话说的就是这个意思呀

京东的 apple care 是分开激活的，要等专人 1 个月内联系你……

不太想离职到底是会不会离职啊。完全不考虑离职=坐等情况发展，出差也得硬去。能不离职就不离职=坐等变化，出差离职。可以考虑离职=赶紧走走走。你其余表达的都是：公司不能这么做。然而公司怎么做，是小职员左右的吗？

为什么投了后端没回复？

毕业前最后一个实习在某电商做这个，感觉其实看你个人吧。我当时就是数据清洗+统计脚本+拷贝开发统计展示页面。大概在 3 个月左右开始接触并且执行数据仓库分层设计，主题表设计什么的。然后根据日常统计 80%都差不多的统计逻辑设计了一个只写 sql 就出统计的 base 脚本，加快了开发速度。然后又研究每天最基础的清洗表脚本的速度有问题持续优化到耗时五分之一。然后发现可视化的逻辑也都差不多，于是又跟前端同学抽象了一个根据数据统计结果的 sql 生成前端图标的工程。之后在不断的统计需求中，发现 app 和 web 之类的日志系统有点问题，然后提出加入请求 ID 追踪。参与当时最重视数据科学的 growth hacker 项目，学到了分析师看数据的侧重点和不断迭代的思路。最终组里面除了算法真是没基础，别的职能随便做。10 个月都是实习，从第一个需求反复出错，被对方拉着我们组老大点名批评，到最后工作交接要 4 个全职员工参与。我觉得，不管什么职位，认真思考它给了你做什么东西的机会，它暴露了什么问题，你能做出什么改变，这是最重要的。（吹完一波赶紧跑

对薪资待遇提升方面，建议楼主慎重思考一下。如果当前的薪资对你来说非常不公平，你再把这个当做一个重点来看。如何对待“待遇”是有一些陷阱在的：往往感觉不公平，不是待遇不够，而是比较他人得出的，然而这个世界的多样性如果只被限制在“某个人该拿多少与他实际拿多少”这两个因素上，就有点浅显了；待遇之类这种外在奖励，就算提升了，也会在短时间内被人适应，进而滋生下一阶段的不满。对于工作中的幸福感，建议从内在解决。

你打几盘就知道自己是真老了……

这个和那个 试用期被要求开发 OA 的是啥关系？/t/384498

28 关过不去了，单词找到了，密码输不对，烦躁

组件父级应该有这个组件绑定的 key?那么后端返回这个 key 的当前值时，是不是先设置父级，再修改组件值？如果这个流程的话，组件 change 里面判断当前是不是等于父级 key 就能解决。

TD、TD 退订、复 TD、复 TD 退订 都试过了吗

完全反对加班文化

@az8321550924 23333，我从那个防止过度滑动的帖子看你就回复了一个已经 hack 实现，但是你没贴 demo 连接。结果到这个帖子看到了正确的回复。逻辑判断写成赋值语句导致 ID 变化，结果资源更新错了地方的既视感。

拿 python request 下好内容自己拼一个 html 存在临时目录，然后 system 一个 open/start 这个 html 不就可以了吗？