人工查询的话，天地图，行政区划

在乎这个干啥，想要键盘，直接一整套，然后老的一套全都一次清出。不想那么多

我的策略，直接安装 google maps 和 google earth 。

沁园基础的五级过滤，不就够了么？又不往直饮方向搞。中国人喝水，还是偏向于烧开、凉凉。

我开非 80 、443 端口，没人管，但是 80 和 443 运营商是直接拒绝的，开了也没用

除非自己是做 PAAS 的，否则谁敢动容器，到了客户那里需要专门指配容器，那还不如传统部署方式

回 LZ，招标文件，几百万那不叫报价，那叫预算。你给出的，才是投标报价，你要根据招标内容，测算自己的工作量，算出投入规模，得出成本，然后再说利润。当然了，也不排除赔本赚吆喝，放长线钓大鱼的。

源码这事，看标书，更准确地是看合同。甲方要求源码，那就明确知识产权，软著归谁，代码是一个层面，知识产权软著是另外一个层面——但普遍无法严格区分。

哦，好像看岔了。LZ 应该是甲方，重说。
有投标文件，那肯定有招标文件，招标文件怎么说的，预算多少，招标文件明确了建设内容和商务内容，报价属于商务部分，不高于招标价格，不违反招标条款，那就是有效标书，后期按照招标文件评分办法（由评标委员会）给分评出 1 、2 、3 来。至于价格么，招标文件中的预算价格怎么测算的，那按照 @jy02201949 1# 2# 说的，（可能）经过了测算评估。

@typetraits 5# 快拉倒吧。做出来容易，甚至找个开源的改吧改吧，后边维护改进谁来做？业务迭代谁来搞？不把老师搞死（学生是流动的，无所谓），老师可能也不想继续陷泥坑。这还不说老师的团队有没有工程化经验。

当然了，作为乙方，你当时搞得的那个东西，可以再问一问后续进展，是顺利开展还是甲乙方打架。

当然我是甲方，我这么说，要是 LZ 的甲方有能力能自己接盘，那我说的都是废话。

想事要往最坏的打算，做事要往最好的努力。

捕蝇草

NB-IOT，刷卡，最省事，不要用密码
然后门锁无法确定开闭状态，门吸可以。或者门锁+门开合检测器

网站运营方这么搞，成本太高，除非自己就是广告渠道商。

@lihua 14# Θ..Θ

你要想，apple 在下什么样的大棋，macos 跟 ipados 本质区别是什么，或者说 macos 往 ipad 上下放，有什么样的难点。
首先说，两个系统一定程度上在 APP 上开始互通，所以从 OS 内核维度上，系统调用趋于一致。
然后说，因为两者源起的屏幕尺寸不一致，会导致其用户交互的方式不一致——从来没有过直接戳 MacOS 的屏幕进行交互的吧；自大屏 IPAD 开始，支持键盘和鼠标的交互了吧——所以进一步统一两者的交互模式，macos 和 ipados 融合。
最后，ipadmini 怎么办，同样都是 ipados，兼顾了 8 、10/11 、12 三种尺寸，我唯一在用的就是 ipadmini，我始终坚信 ipadmini 不是 ipad 的 mini，而是 iphone 的 max，同时随着柔性屏的使用，ipadmini 应当被同化入 iphone 体系，而 ipad(pro)应当归入 macos 体系。

所以，这不是装不装 macos 的问题，而是 macos 和 ipados 两条产品线怎么整合的问题了。

我觉得 AC68 的那个 CPU，做 NAT，大带宽会显得吃力

LZ 没有实操过吧，使用文件形式 MyISAM 存储的 mysql，过一段时间时间，表就得 optimize 一下清理碎片，INODB 会好一些。
这个事情涉及到 DBMS 的设计规则，最上层的表征当然是一个 SELECT 的效率，但是其中涉及到数据模型（表）的存储设计，操作系统的文件机制（磁盘分区格式）以及操作系统层以下的磁盘阵列机制（再往下就是单盘内部的缓存和存储组织形式）。
诚如楼上两回复所示，操作系统文件管理机制在其中，并不是最关键的，普遍 DBMS 会向 OS 申请一个较大的空间，然后文件系统决定是连续存储还是分片存储，所以为了进一步压榨，干脆把整盘独占给 DBMS——这个整盘并不是物理上的整盘而是经过了软硬件机制整合过的整块存储区。那么透过其本质，实际上就是 DBMS 在做一个文件存储系统，再进一步说，如果这台服务器事实上只处理 DBMS，那么是不是可以把 DBMS 和 OS 合并在一起，所以 Oracle 有数据库一体机，OS 经过调教，虽然还是 unix-like，但已经无关紧要了。

修正 5# 奥维地图