戰(zhàn):從零構(gòu)建服裝生產(chǎn)管理系統(tǒng)的完整方案)
1. 項(xiàng)目背景與需求拆解1.1 服裝生產(chǎn)管理到底管什么先說(shuō)這個(gè)項(xiàng)目的由頭。服裝生產(chǎn)的流程和別的行業(yè)不太一樣它不是一條簡(jiǎn)單的流水線而是典型的“離散批量”混合模式客戶下訂單、技術(shù)部打樣板、采購(gòu)面料輔料、裁剪車(chē)間鋪料開(kāi)裁、縫制車(chē)間分組加工、后道車(chē)間整燙包裝、質(zhì)檢、入庫(kù)、發(fā)貨。每一個(gè)環(huán)節(jié)都牽扯到人、料、單三方數(shù)據(jù)的聯(lián)動(dòng)。傳統(tǒng)做法是拿Excel管小廠能扛一旦訂單到了每天幾十張、款式頻繁翻單、面輔料上百個(gè)品種的時(shí)候Excel就開(kāi)始失控了。這個(gè)項(xiàng)目的核心目標(biāo)就是把“人、機(jī)、料、法、環(huán)”這幾個(gè)生產(chǎn)要素在訂單維度上串起來(lái)。說(shuō)得直白一點(diǎn)一件衣服從客戶下意向單到做成成品發(fā)貨每一道工序誰(shuí)做的、用了多少布、縫了多久、有沒(méi)有返工系統(tǒng)里都要有據(jù)可查。項(xiàng)目關(guān)鍵詞里同時(shí)出現(xiàn)了flask和django這里插一嘴。這個(gè)項(xiàng)目最終選用的是Flask實(shí)現(xiàn)核心功能標(biāo)題里帶django大概率是選型階段曾經(jīng)對(duì)比過(guò)或者是在學(xué)習(xí)過(guò)程中兩個(gè)框架都接觸過(guò)。實(shí)際上這兩個(gè)框架各有優(yōu)勢(shì)后面我會(huì)單獨(dú)說(shuō)選型的事。1.2 適合誰(shuí)來(lái)參考這個(gè)項(xiàng)目最適合兩類(lèi)人。一類(lèi)是正在做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)的信息管理類(lèi)學(xué)生服裝生產(chǎn)這個(gè)選題比傳統(tǒng)的“學(xué)生管理系統(tǒng)”“圖書(shū)管理系統(tǒng)”值錢(qián)很多因?yàn)闃I(yè)務(wù)流程復(fù)雜、表結(jié)構(gòu)有設(shè)計(jì)空間、功能模塊多能體現(xiàn)完整的軟件工程思路。另一類(lèi)是真的在服裝廠、服裝貿(mào)易公司工作想用低成本的Web方案替代Excel來(lái)管生產(chǎn)的從業(yè)者。不管你是哪類(lèi)人讀完這篇文章你至少能收獲三樣?xùn)|西一是Flask框架從零搭建一個(gè)業(yè)務(wù)系統(tǒng)的完整路徑二是服裝生產(chǎn)領(lǐng)域的核心業(yè)務(wù)表結(jié)構(gòu)設(shè)計(jì)思路三是一堆我在實(shí)際開(kāi)發(fā)中踩過(guò)的坑和填坑方案。2. 技術(shù)選型為什么最終選了Flask2.1 Flask和Django的取舍邏輯標(biāo)題里同時(shí)出現(xiàn)了flask和django我先把這個(gè)事情講透因?yàn)檫@兩者的選擇直接決定整個(gè)項(xiàng)目的開(kāi)發(fā)節(jié)奏。Django是“全家桶”路線自帶ORM、Admin后臺(tái)、表單處理、認(rèn)證系統(tǒng)、模板引擎開(kāi)發(fā)一個(gè)標(biāo)準(zhǔn)的信息管理系統(tǒng)非???。但它的缺點(diǎn)是“重”項(xiàng)目一旦起來(lái)目錄結(jié)構(gòu)、配置方式、模型注冊(cè)邏輯都是約定好的靈活性相對(duì)受限。Flask則是“輕量級(jí)微框架”核心只做路由和視圖其他功能通過(guò)第三方擴(kuò)展按需組裝。那為什么這個(gè)項(xiàng)目選Flask三個(gè)原因。第一服裝生產(chǎn)管理系統(tǒng)的業(yè)務(wù)是高度定制的。你知道嗎每個(gè)工廠的工序流轉(zhuǎn)邏輯都不一樣有的廠是裁剪和縫制分開(kāi)有的廠是“裁剪-縫制-鎖釘-整燙”一條龍有的廠按訂單組織生產(chǎn)有的廠按批次加庫(kù)別管理。Django的Admin能幫你快速做一個(gè)CRUD后臺(tái)但真正貼合業(yè)務(wù)邏輯的交互流程還是要自己寫(xiě)。既然都要自己寫(xiě)選一個(gè)更輕、路由和視圖邏輯更直觀的框架開(kāi)發(fā)體驗(yàn)反而更舒服。第二這個(gè)系統(tǒng)的并發(fā)量和服務(wù)體量都不大。Flask配合GunicornMySQL完全能扛住上百人的同時(shí)在線操作沒(méi)必要為一個(gè)工廠內(nèi)部系統(tǒng)引入Django的全套機(jī)制。第三Flask的ORM用flask-sqlalchemy和藍(lán)圖Blueprint機(jī)制對(duì)于一個(gè)業(yè)務(wù)邊界清晰的管理系統(tǒng)來(lái)說(shuō)代碼組織起來(lái)非常干凈。后面我會(huì)詳細(xì)展開(kāi)。2.2 開(kāi)發(fā)工具鏈組合開(kāi)發(fā)環(huán)境這塊官方推薦的組合是Python 3.9系統(tǒng)開(kāi)發(fā)語(yǔ)言建議用3.10或3.11長(zhǎng)期支持版本Flask 2.3Web框架flask-sqlalchemy 3.0ORM組件flask-wtf表單驗(yàn)證flask-login登錄會(huì)話管理MySQL 5.7 或 SQLite開(kāi)發(fā)期可用SQLite部署切換到MySQLPycharm Professional數(shù)據(jù)庫(kù)工具、Jinja2模板提示、斷點(diǎn)調(diào)試都很順手Pycharm在這套組合里的價(jià)值比很多新手以為的大得多。它的Database插件能直接連MySQL查看表結(jié)構(gòu)和數(shù)據(jù)Jinja2模板的自動(dòng)補(bǔ)全能省不少拼寫(xiě)錯(cuò)誤調(diào)試器配合Flask的debug模式可以做完整的斷點(diǎn)追蹤。用Community版也能開(kāi)發(fā)但Professional版在工程效率上的提升是肉眼可見(jiàn)的。3. 系統(tǒng)設(shè)計(jì)與數(shù)據(jù)庫(kù)建模3.1 模塊劃分整個(gè)系統(tǒng)我拆成了七個(gè)核心模塊每個(gè)模塊對(duì)應(yīng)一組Blueprint用戶權(quán)限模塊系統(tǒng)登錄、角色區(qū)分管理員、生產(chǎn)主管、車(chē)間組長(zhǎng)、檢驗(yàn)員、倉(cāng)庫(kù)管理員訂單管理模塊訂單創(chuàng)建、訂單明細(xì)、生產(chǎn)進(jìn)度跟蹤物料管理模塊面輔料檔案、采購(gòu)入庫(kù)、領(lǐng)料出庫(kù)、庫(kù)存預(yù)警生產(chǎn)管理模塊裁剪記錄、縫制工序流轉(zhuǎn)、工序報(bào)工質(zhì)量管理模塊檢驗(yàn)記錄、返工記錄、次品統(tǒng)計(jì)成品管理模塊成品入庫(kù)、發(fā)貨出庫(kù)統(tǒng)計(jì)報(bào)表模塊訂單進(jìn)度報(bào)表、物料消耗報(bào)表、計(jì)件工資統(tǒng)計(jì)這里有一個(gè)設(shè)計(jì)上的思考要點(diǎn)不要把所有數(shù)據(jù)都塞在一個(gè)“訂單”里。比如物料和生產(chǎn)工序是動(dòng)態(tài)變化的數(shù)據(jù)如果都掛在訂單子表里查詢和統(tǒng)計(jì)都會(huì)變得非常吃力。我采取的是“訂單—批次—工序”三層結(jié)構(gòu)訂單可以有多個(gè)生產(chǎn)批次批次下面跟蹤多道工序狀態(tài)。這樣既貼近工廠實(shí)際操作又方便做報(bào)表統(tǒng)計(jì)。3.2 核心數(shù)據(jù)表設(shè)計(jì)我挑幾張最有代表性的表來(lái)說(shuō)這幾張表是整個(gè)系統(tǒng)的基礎(chǔ)設(shè)計(jì)好了后面的代碼會(huì)順利很多。用戶表users——除了常規(guī)的username、password_hash、role建議加一個(gè)workshop字段標(biāo)識(shí)屬于哪個(gè)車(chē)間這樣權(quán)限控制可以細(xì)到車(chē)間級(jí)別。訂單表orders——字段包括訂單號(hào)order_no、客戶名稱、款號(hào)style_no、顏色、數(shù)量、下單日期order_date、交貨日期delivery_date、狀態(tài)status。這里訂單號(hào)一定要設(shè)計(jì)成可讀性好的業(yè)務(wù)編碼比如20251201-A001表示2025年12月1日接的A客戶第1單這樣在生產(chǎn)和溝通中直接報(bào)訂單號(hào)就能定位。訂單明細(xì)表order_items——一個(gè)訂單可以有多個(gè)款式每個(gè)款式對(duì)應(yīng)一條明細(xì)記錄款號(hào)、規(guī)格、數(shù)量、單價(jià)、總價(jià)。這塊是計(jì)算訂單總額和生成生產(chǎn)任務(wù)單的基礎(chǔ)數(shù)據(jù)。面輔料表materials——類(lèi)型面料/里料/輔料、編號(hào)、品名、規(guī)格、單位、庫(kù)存量、安全庫(kù)存量。安全庫(kù)存是預(yù)警的關(guān)鍵低于閾值就要提醒采購(gòu)。生產(chǎn)批次表batchs——關(guān)聯(lián)訂單明細(xì)和它在哪個(gè)車(chē)間生產(chǎn)、批次號(hào)、計(jì)劃產(chǎn)量、裁床數(shù)量、開(kāi)始時(shí)間、結(jié)束時(shí)間、狀態(tài)。批量生產(chǎn)時(shí)裁剪數(shù)量通常會(huì)做調(diào)整比如加10%的損耗批次的實(shí)際裁剪數(shù)量和理論生產(chǎn)數(shù)量要區(qū)分。工序報(bào)工表process_records——這是計(jì)件工資和生產(chǎn)進(jìn)度的核心表。字段包括批次號(hào)、工序名稱裁剪/縫制/鎖釘/整燙/質(zhì)檢、操作工ID、完成數(shù)量、生產(chǎn)日期、檢驗(yàn)結(jié)果。注意這里不能只存“完成數(shù)量”還要存“返工數(shù)量”因?yàn)闄z驗(yàn)環(huán)節(jié)一旦發(fā)現(xiàn)不合格返工也會(huì)直接影響工效統(tǒng)計(jì)。物料出入庫(kù)表material_flows——記錄每一筆面輔料的入庫(kù)量、出庫(kù)量、對(duì)應(yīng)訂單/批次、操作時(shí)間、操作人。這是庫(kù)存報(bào)表和追溯的底子。成品出入庫(kù)表finished_goods_flows——結(jié)構(gòu)和物料出入庫(kù)類(lèi)似但對(duì)應(yīng)的是成品款號(hào)和數(shù)量。這套表結(jié)構(gòu)的核心邏輯就是“主數(shù)據(jù)事務(wù)流水”分離檔案類(lèi)數(shù)據(jù)用戶、物料、訂單主表穩(wěn)定事務(wù)類(lèi)數(shù)據(jù)出入庫(kù)、報(bào)工、檢驗(yàn)全部走流水。這樣設(shè)計(jì)的好處是查詢性能好、歷史可追溯、統(tǒng)計(jì)口徑統(tǒng)一。3.3 生產(chǎn)主流程的流轉(zhuǎn)設(shè)計(jì)接下來(lái)是業(yè)務(wù)流程如何映射到代碼邏輯。最核心的生產(chǎn)閉環(huán)是訂單下達(dá) → 生成生產(chǎn)批次 → 物料準(zhǔn)備面輔料入庫(kù)后按批次領(lǐng)料 → 裁剪報(bào)工 → 縫制工序報(bào)工 → 質(zhì)檢記錄 → 合格品入庫(kù) → 發(fā)貨這個(gè)流程里有一個(gè)容易忽視的設(shè)計(jì)點(diǎn)狀態(tài)的流轉(zhuǎn)要閉環(huán)。我用了order_status字段存一個(gè)整數(shù)類(lèi)型的枚舉值0待排產(chǎn)、1生產(chǎn)中、2已完工、3已發(fā)貨。每次關(guān)鍵操作領(lǐng)料、裁剪、質(zhì)檢、入庫(kù)之后都要調(diào)用一個(gè)update_order_progress()函數(shù)來(lái)刷新訂單狀態(tài)。比如某個(gè)訂單的所有批次都完成了狀態(tài)就自動(dòng)改成“已完工”。這個(gè)邏輯看起來(lái)簡(jiǎn)單但沒(méi)有了它系統(tǒng)就會(huì)變成一堆獨(dú)立的CRUD頁(yè)面和Excel沒(méi)有任何區(qū)別。4. 開(kāi)發(fā)環(huán)境搭建與Flask工程結(jié)構(gòu)4.1 Pycharm環(huán)境配置要點(diǎn)拿Pycharm新建項(xiàng)目的時(shí)候我建議選虛擬環(huán)境virtualenv不要用全局Python解釋器。為什么因?yàn)镕lask項(xiàng)目對(duì)依賴版本比較敏感尤其是flask-sqlalchemy和SQLAlchemy的版本搭配虛擬環(huán)境能保證不同項(xiàng)目之間互不干擾。Pycharm新建項(xiàng)目時(shí)選擇Virtualenv環(huán)境Python版本指向本機(jī)已安裝的3.10然后項(xiàng)目創(chuàng)建好之后在Terminal窗口執(zhí)行以下命令安裝依賴pip install flask flask-sqlalchemy flask-wtf flask-login pymysql cryptography這里有三個(gè)容易踩坑的點(diǎn)。第一MySQL8.0的加密規(guī)則是caching_sha2_passwordpymysql在5.x以下版本不兼容裝cryptography庫(kù)可以解決認(rèn)證問(wèn)題。第二不要漏裝flask-wtf里的wtforms依賴表單處理后面會(huì)用到。第三如果開(kāi)發(fā)期不想裝MySQL可以先連SQLite代碼里的數(shù)據(jù)庫(kù)連接字符串切一下就行后面我講怎么配置。4.2 工程目錄結(jié)構(gòu)一個(gè)中型Flask項(xiàng)目不要把所有代碼堆在app.py里。推薦劃分如下app/ __init__.py # 應(yīng)用工廠初始化app、db、login_manager models/ # 數(shù)據(jù)模型 __init__.py user.py order.py material.py production.py quality.py blueprints/ # 藍(lán)圖模塊 auth/ # 登錄登出 order/ # 訂單管理 material/ # 物料管理 production/ # 生產(chǎn)報(bào)工 quality/ # 質(zhì)量管理 report/ # 報(bào)表 templates/ # Jinja2模板 static/ # 靜態(tài)資源css/js/img utils/ # 工具函數(shù)訂單號(hào)生成、權(quán)限裝飾器 config.py # 配置文件數(shù)據(jù)庫(kù)連接、SECRET_KEY run.py # 啟動(dòng)入口這里最關(guān)鍵的是__init__.py里的“應(yīng)用工廠”模式。它允許你在測(cè)試、生產(chǎn)環(huán)境里創(chuàng)建不同的應(yīng)用實(shí)例參數(shù)靈活。核心代碼如下from flask import Flask from flask_sqlalchemy import SQLAlchemy from flask_login import LoginManager from config import Config db SQLAlchemy() login_manager LoginManager() def create_app(config_classConfig): app Flask(__name__) app.config.from_object(config_class) db.init_app(app) login_manager.init_app(app) login_manager.login_view auth.login # 注冊(cè)藍(lán)圖 from app.blueprints.auth import bp as auth_bp app.register_blueprint(auth_bp, url_prefix/auth) from app.blueprints.order import bp as order_bp app.register_blueprint(order_bp, url_prefix/order) # 其他藍(lán)圖類(lèi)似注冊(cè) return app配置文件config.py核心內(nèi)容import os class Config: SECRET_KEY os.environ.get(SECRET_KEY) or your-secret-key-change-me SQLALCHEMY_DATABASE_URI os.environ.get(DATABASE_URL) or \ mysqlpymysql://root:passwordlocalhost:3306/garment_db?charsetutf8mb4 SQLALCHEMY_TRACK_MODIFICATIONS False注意這里的連接串一定要帶charsetutf8mb4否則存中文和特殊字符容易出亂碼這是無(wú)數(shù)人踩過(guò)的坑。4.3 為什么不把數(shù)據(jù)庫(kù)選型一步到位用MySQL開(kāi)發(fā)階段我建議先用SQLite部署時(shí)再切MySQL。原因很簡(jiǎn)單SQLite零配置、單文件、方便開(kāi)發(fā)調(diào)試開(kāi)箱即用。等系統(tǒng)跑通了再把連接串切換到MySQL。flask-sqlalchemy的好處就是ORM層統(tǒng)一切換數(shù)據(jù)庫(kù)幾乎不用改業(yè)務(wù)代碼最多改一下配置。如果你用的是Pycharm ProfessionalSQLite文件可以直接右鍵打開(kāi)像普通數(shù)據(jù)庫(kù)一樣瀏覽表數(shù)據(jù)開(kāi)發(fā)體驗(yàn)非常友好。5. 核心功能模塊的實(shí)現(xiàn)細(xì)節(jié)5.1 登錄與權(quán)限控制的實(shí)現(xiàn)認(rèn)證用的是flask-login。首先創(chuàng)建用戶模型密碼存hash值絕不存明文from werkzeug.security import generate_password_hash, check_password_hash from flask_login import UserMixin from app import db, login_manager class User(UserMixin, db.Model): __tablename__ users id db.Column(db.Integer, primary_keyTrue) username db.Column(db.String(80), uniqueTrue, nullableFalse) password_hash db.Column(db.String(256), nullableFalse) role db.Column(db.String(20), nullableFalse, default員工) workshop db.Column(db.String(50), nullableTrue) def set_password(self, password): self.password_hash generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) login_manager.user_loader def load_user(user_id): return db.session.get(User, int(user_id))登錄視圖和模板就是標(biāo)準(zhǔn)的flask-login流程校驗(yàn)用戶名密碼、記錄session、跳轉(zhuǎn)到首頁(yè)。權(quán)限控制這塊我用了一個(gè)自定義裝飾器限制某些操作只能由指定角色執(zhí)行from functools import wraps from flask import abort from flask_login import current_user def role_required(*roles): def decorator(f): wraps(f) def decorated_function(*args, **kwargs): if current_user.role not in roles: abort(403) return f(*args, **kwargs) return decorated_function return decorator這樣在涉及物管、統(tǒng)計(jì)這類(lèi)頁(yè)面時(shí)只要加一行role_required(管理員, 倉(cāng)庫(kù)主管)權(quán)限邊界就清晰了。注意裝飾器的順序login_required要放在最外層。5.2 訂單管理模塊的實(shí)現(xiàn)思路訂單模塊是業(yè)務(wù)的入口。頁(yè)面上需要訂單列表分頁(yè)狀態(tài)篩選、訂單詳情基本信息明細(xì)關(guān)聯(lián)批次、新增訂單、編輯訂單。新增訂單的表單我用了flask-wtf來(lái)校驗(yàn)from flask_wtf import FlaskForm from wtforms import StringField, IntegerField, DateField, SubmitField from wtforms.validators import DataRequired, Length, NumberRange class OrderForm(FlaskForm): customer StringField(客戶名稱, validators[DataRequired(), Length(max100)]) style_no StringField(款號(hào), validators[DataRequired(), Length(max50)]) color StringField(顏色, validators[Length(max50)]) quantity IntegerField(數(shù)量, validators[DataRequired(), NumberRange(min1)]) order_date DateField(下單日期, validators[DataRequired()]) delivery_date DateField(交貨日期, validators[DataRequired()]) submit SubmitField(保存)訂單號(hào)用函數(shù)自動(dòng)生成不靠用戶手輸from datetime import datetime def generate_order_no(customer_code): timestamp datetime.now().strftime(%Y%m%d) return f{timestamp}-{customer_code}-{str(order_id).zfill(4)}這種方式生成的訂單號(hào)有業(yè)務(wù)含義查詢方便在印刷的生產(chǎn)流轉(zhuǎn)單上也好溝通。5.3 庫(kù)存管理的核心操作報(bào)工驅(qū)動(dòng)出入庫(kù)這是整個(gè)系統(tǒng)最有業(yè)務(wù)價(jià)值的部分。操作的觸發(fā)邏輯是面料采購(gòu)到貨后填寫(xiě)入庫(kù)單增加materials庫(kù)存生產(chǎn)批次開(kāi)工后填寫(xiě)領(lǐng)料單減少面料庫(kù)存關(guān)聯(lián)到批次縫制完工后填寫(xiě)報(bào)工單按款號(hào)生成成品入待檢區(qū)數(shù)量質(zhì)檢合格后填寫(xiě)成品入庫(kù)單增加finished_goods_flows這里我采用了“事務(wù)”機(jī)制每一次操作要么全部執(zhí)行成功要么全部回滾絕對(duì)不能出現(xiàn)“庫(kù)存減了但流水沒(méi)記”的情況。from app import db def material_out(batch_id, material_id, quantity, operator_id): try: # 檢查庫(kù)存 mat db.session.get(Material, material_id) if mat.stock quantity: return {code: 400, msg: f庫(kù)存不足當(dāng)前庫(kù)存{mat.stock}} # 扣減庫(kù)存 mat.stock - quantity # 寫(xiě)流水 flow MaterialFlow( batch_idbatch_id, material_idmaterial_id, typeout, quantityquantity, operator_idoperator_id, flow_timedatetime.now() ) db.session.add(flow) db.session.commit() return {code: 200, msg: 出庫(kù)成功} except Exception as e: db.session.rollback() return {code: 500, msg: f出庫(kù)失敗{str(e)}}這里注意兩點(diǎn)。第一庫(kù)存字段的并發(fā)問(wèn)題。如果多個(gè)車(chē)間同時(shí)領(lǐng)料Python的常規(guī)代碼可能會(huì)丟更新解決辦法是對(duì)庫(kù)存字段加一個(gè)db.Column(db.Integer, nullableFalse)并在更新時(shí)用update().where(...)做原子遞減或者簡(jiǎn)單點(diǎn)用行鎖with_for_update()。第二db.session.rollback()一定要放在異常分支里否則錯(cuò)誤的session狀態(tài)會(huì)帶到下一次請(qǐng)求。5.4 統(tǒng)計(jì)報(bào)表訂單進(jìn)度與計(jì)件工資統(tǒng)計(jì)報(bào)表是管理層最看重的東西也是讓系統(tǒng)“有用”的關(guān)鍵。我做了兩個(gè)核心報(bào)表。第一個(gè)是訂單進(jìn)度看板。按訂單維度聚合批次和工序數(shù)據(jù)展示每個(gè)訂單當(dāng)前完成比例SELECT o.order_no, o.customer, o.status, SUM(b.plan_quantity) AS plan_qty, SUM(CASE WHEN b.status completed THEN b.plan_quantity ELSE 0 END) AS done_qty FROM orders o LEFT JOIN batchs b ON o.id b.order_id GROUP BY o.id在Flask里可以不用裸SQL用SQLAlchemy的db.session.execute(text(...))執(zhí)行原生SQL。報(bào)表場(chǎng)景下原生SQL往往比ORM高效直觀這不算壞味道。第二個(gè)是計(jì)件工資統(tǒng)計(jì)。工廠計(jì)件工資的算法是每道工序單價(jià)乘以完成數(shù)量再考慮返工扣款。工序單價(jià)存在單獨(dú)的process_price表里按款式或工序設(shè)置。def calc_worker_wages(start_date, end_date): records db.session.execute( text( SELECT pr.worker_id, u.username, pr.process_name, SUM(pr.completed_qty) AS total_qty, SUM(pr.defect_qty) AS defect_qty, pp.unit_price FROM process_records pr JOIN users u ON pr.worker_id u.id LEFT JOIN process_price pp ON pr.process_name pp.process_name WHERE pr.work_date BETWEEN :start AND :end GROUP BY pr.worker_id, pr.process_name ), {start: start_date, end: end_date}).fetchall() return records注意這里的LEFT JOIN process_price用的匹配條件是工序名稱。如果在不同車(chē)間里存在同名工序但單價(jià)不同比如A車(chē)間的“鎖釘”和B車(chē)間的“鎖釘”價(jià)格不同那設(shè)計(jì)上就不應(yīng)該用工序名稱做關(guān)聯(lián)鍵而是用“車(chē)間工序”組合鍵這點(diǎn)要提前想清楚不然上線以后算錯(cuò)工資就是大事了。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 問(wèn)題速查表我整理了一個(gè)在開(kāi)發(fā)和部署過(guò)程中最常遇到的問(wèn)題表問(wèn)題現(xiàn)象可能原因解決方案數(shù)據(jù)庫(kù)無(wú)法連接MySQL加密規(guī)則/防火墻/端口未開(kāi)放安裝cryptography庫(kù)檢查3306端口確認(rèn)MySQL服務(wù)已啟動(dòng)中文亂碼連接串缺少charset參數(shù)連接串加?charsetutf8mb4建庫(kù)時(shí)指定utf8mb4字符集靜態(tài)文件加載404模板里url_for(static, filename)路徑寫(xiě)錯(cuò)檢查static目錄位置確認(rèn)文件名大小寫(xiě)表單提交CSRF報(bào)錯(cuò)忘記渲染form.hidden_tag()在模板form標(biāo)簽內(nèi)添加{{ form.hidden_tag() }}登錄后跳轉(zhuǎn)回登錄頁(yè)忘記加載user_loader回調(diào)實(shí)現(xiàn)login_manager.user_loader函數(shù)刪除對(duì)象時(shí)報(bào)外鍵約束錯(cuò)誤有子表數(shù)據(jù)關(guān)聯(lián)先處理關(guān)聯(lián)子表或使用db.session.delete后再commit內(nèi)存占用高debug模式開(kāi)著生產(chǎn)也在跑生產(chǎn)環(huán)境關(guān)閉debug用Gunicorn部署分頁(yè)失效查詢對(duì)象沒(méi)有執(zhí)行paginate方法使用Model.query.paginate(page, per_page)6.2 值得細(xì)說(shuō)的避坑點(diǎn)第一個(gè)坑Pycharm里虛擬環(huán)境解析器選錯(cuò)導(dǎo)致pip install裝到了全局環(huán)境。這個(gè)問(wèn)題特別隱蔽表現(xiàn)是Terminal里執(zhí)行pip list能看到flask但運(yùn)行時(shí)Python解釋器就是找不到模塊。解決方法是進(jìn)入File → Settings → Project: xxx → Python Interpreter確認(rèn)解釋器路徑指向虛擬環(huán)境目錄下的python.exe。第二個(gè)坑SQLAlchemy模型修改后忘了建表。在開(kāi)發(fā)早期我經(jīng)常加了字段、重啟服務(wù)然后報(bào)錯(cuò)“Unknown column”。Flask-SQLAlchemy不會(huì)自動(dòng)做數(shù)據(jù)庫(kù)遷移需要手動(dòng)執(zhí)行# 在Pycharm的Python Console中執(zhí)行 from app import create_app, db from app.models import * app create_app() with app.app_context(): db.create_all()當(dāng)然正規(guī)的做法是用Flask-Migrate做遷移配合Alembic管理表結(jié)構(gòu)變更。如果項(xiàng)目還在早期db.create_all()夠用一旦數(shù)據(jù)量上來(lái)了建議盡早切到Flask-Migrate否則后期改表結(jié)構(gòu)會(huì)非常痛苦。第三個(gè)坑日期字段的時(shí)區(qū)問(wèn)題。如果服務(wù)器的系統(tǒng)時(shí)區(qū)是UTC而訂單日期、交貨日期顯示出來(lái)都比北京時(shí)間晚8小時(shí)整個(gè)系統(tǒng)的時(shí)間口徑就亂了。解決辦法是在config.py里設(shè)置SQLALCHEMY_ENGINE_OPTIONS { pool_size: 10, pool_recycle: 3600, pool_pre_ping: True, connect_args: { init_command: SET time_zone 08:00 } }pool_recycle和pool_pre_ping是防止MySQL斷開(kāi)連接后導(dǎo)致查詢報(bào)錯(cuò)的常用手段很多部署環(huán)境下的Flask應(yīng)用“運(yùn)行一段時(shí)間后突然報(bào)500錯(cuò)誤”十有八九就是這個(gè)問(wèn)題。7. 項(xiàng)目部署與后續(xù)擴(kuò)展思路7.1 小型生產(chǎn)環(huán)境部署方案如果是工廠內(nèi)部使用不建議直接跑Flask自帶的開(kāi)發(fā)服務(wù)器并發(fā)能力太弱。推薦用GunicornNginx的組合。在服務(wù)器上裝好Python環(huán)境和依賴之后用下面的命令啟動(dòng)pip install gunicorn gunicorn -w 4 -b 0.0.0.0:8000 run:app這里的-w 4表示開(kāi)4個(gè)worker進(jìn)程。如果機(jī)器是2核4G的配置4個(gè)worker差不多能吃滿70%的CPU如果想更穩(wěn)一點(diǎn)可以加--timeout 60防止某個(gè)請(qǐng)求卡死導(dǎo)致worker被當(dāng)成僵尸殺掉。Nginx的配置核心是反向代理和靜態(tài)資源處理。靜態(tài)文件交給Nginx托管Flask只處理動(dòng)態(tài)請(qǐng)求性能會(huì)好很多。server { listen 80; server_name your-server-ip; location /static { alias /path/to/project/app/static; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }7.2 給這個(gè)系統(tǒng)加“外掛”的幾條路這個(gè)項(xiàng)目做完以后如果想繼續(xù)深化有幾條路很值得走。一是報(bào)表可視化。Flask的模板渲染做表格夠用但真要看趨勢(shì)和分布建議在前端集成ECharts用Ajax調(diào)用后端JSON接口。面料庫(kù)存趨勢(shì)、訂單準(zhǔn)交率、各車(chē)間產(chǎn)量對(duì)比全部可視化之后管理層使用意愿會(huì)大幅提升。二是打印功能。服裝生產(chǎn)環(huán)節(jié)里的派工單、檢驗(yàn)單都是要打印出來(lái)線下流轉(zhuǎn)的??梢杂肍lask的模板直接生成可打印的HTML頁(yè)面配合瀏覽器打印的CSS做到無(wú)紙化單據(jù)派發(fā)。三是數(shù)據(jù)的導(dǎo)入導(dǎo)出。面料倉(cāng)管手里往往有現(xiàn)成的Excel臺(tái)賬提供一個(gè)Excel導(dǎo)入面料的入口能把上線初期的數(shù)據(jù)準(zhǔn)備工作節(jié)省80%的時(shí)間。導(dǎo)出用pandas配合openpyxl引擎生成xlsx即可這個(gè)方案網(wǎng)上資料非常多。四是移動(dòng)端適配。車(chē)間里放電腦不現(xiàn)實(shí)但讓班組長(zhǎng)用手機(jī)報(bào)工是完全可行的。讓Flask根據(jù)用戶代理判斷設(shè)備類(lèi)型手機(jī)訪問(wèn)時(shí)渲染一套簡(jiǎn)潔的移動(dòng)端模板就能解決車(chē)間數(shù)據(jù)采集的最后一公里問(wèn)題。根據(jù)我個(gè)人的開(kāi)發(fā)經(jīng)驗(yàn)這類(lèi)管理系統(tǒng)做下來(lái)最容易翻船的不是技術(shù)而是業(yè)務(wù)整理。技術(shù)選型、代碼實(shí)現(xiàn)都是相對(duì)成熟的套路真正的難點(diǎn)在于把工廠里那些“憑經(jīng)驗(yàn)辦事”的隱性規(guī)則梳理成系統(tǒng)的顯性邏輯。比如不同工序的損耗率怎么定、返工品是回原工序還是獨(dú)立處理、面料色差算不算次品這些業(yè)務(wù)口徑不明確系統(tǒng)做出來(lái)就會(huì)被閑置。所以如果你真的要落地一個(gè)生產(chǎn)管理系統(tǒng)花最多時(shí)間的地方不是代碼而是跟車(chē)間主任、倉(cāng)庫(kù)管理員反復(fù)對(duì)口徑。這一關(guān)通過(guò)了項(xiàng)目的價(jià)值和成就感遠(yuǎn)比寫(xiě)幾萬(wàn)行業(yè)務(wù)代碼要大得多。